Hi Folks, while using log4cxx in a project, I've stumbled across small problems with it's default configuration mechanism. The reason for this is, that log4cxx currently sticks a little too close to log4j's ideas. Two points:
1. The current mechanism is using environment variables containing a dot for its configuration. As stated in [1]: "The preferred way to specify the default initialization file is through the log4j.configuration environment variable." Now, the problem is, that it's impossible to create environment variables containing a dot on (at least) Linux systems (or that I'm unable to figure out how), meaning the configuration mechanism in it's current state is broken. I've created a small, backward-compatible patch, that checks a few additional environment variables (like LOG4J_CONFIGURATION), fixing this problem. (Still, log4j.configuration is checked first, in case someone's using that) If you're interested in it, I can either open a bug and attach the patch, or send it to the list (just wanted to ask first what you prefer). 2. log4cxx uses log4j.properties as it's configuration file. Now, while this surely isn't a bug (maybe even by design) I find it somewhat confusing that I configure "log4cxx" using a configuration file referring to "log4j". Besides, this also leads to problems/confusion if you are mixing Java and C/C++ code in a project and accidentally use the log4j.properties file... My suggestion would be to add appropropriate log4cxx keys (log4cxx.configuration, log4cxx.properties, etc.) to the configuration process, using the log4j ones as a fallback. This would enable people to still use a single log4j.properties to configure everything, yet would establish a new (and I think clearer) way of configuring log4cxx with it's own log4cxx.properties file. As this is rather a matter of taste and design, I haven't created a patch yet, but I'd be willing to do so, in case you consider this a good idea. cu Martin
