| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Started working on the async processing
and realised that I need to have a good
copy of the event with all the fields resolved
so this patch has some foundation for the async
functions (module elapi_async.c) but they
are mostly stubbed out.
The actual code will be added down the road.
Instead the patch focuses on the code
introduced in elapi_resolve.c module
and the use of the functions from it.
It also adds the implementation of the
high level calls that initialize ELAPI
with the external callbacks to be used
during async processing (elapi_log.c).
|
| |
|
|
| |
Necessary for RPM builds on RHEL5
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch creates the infrastructure for
logging of the event from the top of the interface
to the bottom. It is a start. A lot of functionality
is left aside.
The attempt of this patch is pass event from caller
of the ELAPI interface via targets to sinks
then to providers and do serialization creating
entity that is ready to be written to a file.
It also implements more specific provider related
configuration parameters.
Also it addresses couple suggestions that were
brought up against previous patch.
ELAPI Correcting issues
This patch addresses the issues found during the
review of the previous patches and addresses
ticket #166.
|
| |
|
|
|
|
|
|
|
| |
This patch drills down to the next level of ELAPI functionality.
I adds the creation and loading of the sinks. It also
implements a skeleton for the first low level provider
which will be capable of writing to a file.
The configuration ini file is extended to define
new configuration parameters and their meanings.
|
|
|
The targets are the destinations which
caller wants to send the events to.
The sinks are now on the second level
under targets and constitute a so called
fail over chain for a target.
Such approach eliminates the need for complex
routing function.
The dispatcher keeps the list of targets in a collection.
The element in the collection is the target context.
Also gispatcher keeps the list of the sinks
in a separate collection.
Each target context has a list of the sinks
associated with this target. But those are just
pointers (at least for now) to the sinks
form the list kept by dispatcher.
I had to add some internal debug callbacks
to be able to see that all the internals of
the dispatcher are actually in order.
See the conttent of config file for more comments.
Also see information posted on SSSD wiki.
https://fedorahosted.org/sssd/wiki/WikiPage/ELAPIInterface
|
