Logging within the package

The package uses itself for logging similar to Log4j 1.3. This brings much more flexibility over logging to stdout, stderr like in Log4j 1.2 using logLog. It also enables the program to capture and handle errors raised by the package.

Using this approach introduces the issue of recursion. The following example explains a situation where this happens. Let's say all logger are configured to be additive and only the root logger has an appender set. The appender is a FileAppender. During the logging of an event an I/O error occurs. The FileAppender logs an event by itself using the logger Log4QtFileAppender. The event is passed to the root logger, which calls then the FileAppender. This causes another I/O error, which is logged by the FileAppender.

To avoid an endless loop the appender will drop the event on a recursive invocation. This check is done by AppenderSkeleton in doAppend().

The problem only occurs, if a logger, appender, layout or filter log an event while an event is appended. Neither the logger class nor any of the layout or filter classes log events during appending of an event. Most of the appender classes may log errors during appending. Only the ListAppender and ConsoleAppender are not logging events.

The default configuration uses two ConsoleAppender, one for stderr and one for stdout. No event will be dropped, because no recursive invocations can occur.