Perhaps you have read this last year and now the problems with the TimeZone management I mentioned with the 8.5.2 release.
In that release log messages were used in the timeZone-code. The most interesting part is how the author of the TimeZone application uses log4s.
As an example:
System logManager loggerNamed: 'timeZones' warn: aString locationInfo: locationInfo.
It uses its own logger named ‘timeZones’. The idea behind might be to isolate the messages from a subsystem against the rest of the system.
The first problem with this approach is, that you might actually not know, what possible logger names are used around the code in the whole system. Therefore without any additional infrastructure this seems to be not manageable – and you might not get the error messages you actually want to have.
A solution could be to introduce a mapper within the instance of EsLogManager – which maps loggerNames to actual instances of loggers. And one default mapping is to map ALL ever used logger names to the root logger, which is always available.
The next problem is, that – out of the box – log4s only initializes the structures needed for logging only based on the definitions in its own section “log4s”.
Therefore normally ALL logging definitions needed for the whole system (including my own needs) should be located in the “log4s” section and the author of log4s assumed this usage. As an example for the SocketAppender you must define the logging structures for EsLoggingFrameworkSocketSupport in “log4s” and NOT in its own possible section “EsLoggingFrameworkSocketSupport”.
Therefore without extending log4s we have one design limitation: all logging definitions are defined in the “log4s” section.
Remember the fact, that the “ini”-structure is only a key-value data structure. You can NOT have multiple keys with the same values.
Therefore – in this version – you can only create ONE additional logger. Because you can only have ONE “createLogger” statement in that ini section.
That means: you always have the root logger and ONE additional logger you may define. But wait – what about the “timeZone” logger mentioned above or other logger we yet not know of ??? Impossible to handle. If you define your own additional logger – all messages of “timeZone” are lost.
But now to the appender entries (the output channels) in your log4s-section. Remember the key-value limitations of an ini section? Due to that you can only define ONE consoleAppender and connect it to ONE logger. What about having the output of rootLogger, the “timeZone”-logger and my own logger ALL to console ? Not possible !! Whatever you do – some messages are always lost.
Ok, what does this mean for the user of log4s ?
* NEVER, EVER define your own logger. Use the “root” logger for all the stuff you are doing on your own. All other stuff is not really supported.
And please still consider this.