log4cxx configuration mechanism

[Martin Landers <ma...@jambit.com>]

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