Curt,
I don't know if you've looked at the source code of Joran but I trust that you'll find it quite simple, if not trivial. The only part I found mildly challenging were writing actions that could be self-nested. Currently, this can only happen with o.a.l.joran.action.NestComponentIA.
There is a Joran tutorial in LOG4J_HOME/examples/src/joran
Regarding non-ASCII characters for file names, logger names etc, Joran just takes in the data supplied by the parser. It does not attempt to perform any character conversions. Anyway, isn't correctly decoding the character data the responsibility of the XML parser?
At 09:33 PM 11/26/2004, you wrote:
log4j 1.3 contains an upward compatible replacement of the DOMConfigurator called the Joran Configurator (named after a wind that blows over Lac Laman) https://www.qos.ch/logging/joran.pdf.
There are a couple of forthcoming changes that will require working on the existing log4cxx DOMConfigurator and it may be better to just drop the current implementation and port over the JoranConfigurator. The existing DOMConfigurator depends on libxml2 or MSXML depending on the platform. MSXML is particularly troublesome since it requires initializing COM and may have fairly substantial side-effects. Also, I don't know the how the current DOMConfigurator handles non-ASCII characters for file names, logger names, etc, but it is likely that it doesn't do that well and would need changes after the Unicode modifications.
My current thoughts are to drop DOMConfigurator from log4cxx, do the Unicode fixes to the rest of the project and then port the JoranConfiguator using APR's XML parser driver and typedef DOMConfigurator as an alias for JoranConfigurator.
I would appreciate any comments.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
