ELAPI: Adding concept of targets

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

1 files changed, 97 insertions, 0 deletions

diff --git a/common/elapi/elapi_test/elapi_ut.conf b/common/elapi/elapi_test/elapi_ut.conf
new file mode 100644
index 000000000..d15a4550d
--- /dev/null
+++ b/common/elapi/elapi_test/elapi_ut.conf
@@ -0,0 +1,97 @@
+; This is a sample configuration file for ELAPI
+
+; The dispatcher section defines general configuration
+; for the ELAPI. It has following configuration parameters:
+;
+; targets - (required)
+;           Defines possible logical destinations where message can be sent.
+;           It is one of the arguments of the calling interface. It is numeric.
+;           It is done this way for performance reasons so it is faster to compare.
+;           But in the configuration it is easier to deal with targets as strings.
+;           To overcome this issue each target is assigned a number in the INI file.
+;           The ELAPI convention is to have three default targets:
+;           "debug", "audit" and "log" but application developers can add others as needed.
+;           The default value for debug target is 1, for audit 2 and log is 4.
+;           Changing the value defined for debug to be 7 ( logical OR of 1, 2 and 4)
+;           will result in all messages sent into debug log.
+;           This might be convenient during troubleshooting and would allow seeing all
+;           events emitted by the application in one place.
+;           If you want the event to be sent into two targets at the same time
+;           add a target with different name but same value.
+;           For example if the log events need to go to local and remote files
+;           in parallel you would create another target: logremote
+;           and give it same value as log (which by convention is 4)
+
+
+
+[dispatcher]
+targets=debug, audit, log
+
+; Inside section for each target the following parameters can be defined:
+;
+; value - (optional)
+;         Stores the value associated with this target.
+;         If the bit-wise AND of this value and the value provided by caller
+;         of the interface is greater than 0 the event is logged into the
+;         target destination. If omitted all events are sent to this target.
+; sinks - (required)
+;         Defines the list of the sink names that need to be loaded
+;         each will have its own section.
+;         Only one of the sinks is active - first in the list.
+;         The list contains sinks in the fail over order.
+;
+
+[debug]
+value = 1
+sinks = debugfile, stderr
+
+[audit]
+value = 2
+sinks = auditfile, syslog
+
+[log]
+value = 4
+sinks = logfile, syslog
+
+; Each sink needs to have it's own section.
+;
+; COMMON FOR EVERY SINK
+;
+; provider - (required)
+;            Defines the name of the sink or the special reserved word to
+;            indecate that it is a sink provided natively by ELAPI library.
+;
+;            Special sinks provided natively by ELAPI are:
+;             file
+;             stderr
+;             syslog
+;
+;            Example:
+;            provider=file
+;
+;            this would mean the destination for this sink is a file.
+;
+;            If the sink is provided as an external plugin
+;            the syntax should be the following:
+;
+;            provider=custom_audit
+;
+;            In this case the ELAPI will try to load shared library with the name
+;            constructed using specified value. In the given example
+;            ELAPI will try to load libelapi_sink_custom_audit.so library.
+;            The general pattern is: libelapi_sink_<source>.so
+
+[debugfile]
+provider=file
+
+[logfile]
+provider=file
+
+[auditfile]
+provider=file
+
+[stderr]
+provider=stderr
+
+[syslog]
+provider=syslog