commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sun, 26 Dec 2004 16:23:49 GMT

Simon et al.

Log4j is slowly migrating to a model where there will be only a single
log4j.jar installed per Application Server. This single copy will be
installed under the ./common/lib or ./lib/ directories. See [1, 2, 3] for
further details.

Consider the case of single log4j.jar placed in ./common/lib, and two
web-applications called 'A' and 'B' both built on top of Struts. Also
assume that user of 'A' wishes to use JDK logging (j.u.l) whereas the
user of application 'B' wishes to use log4j. Since Struts uses JCL,
there is no way for user of application 'A' to direct the logs
generated by Struts to go to j.u.l and at the same time to have Struts
in application 'B' direct its logging output to log4j. (Setting the
org.apache.commons.logging.LogFactory system property will not help
because system properties are shared by all applications.)

This simple example shows that the current JCL discovery mechanism
will not always work as intended.


On 2004-12-10 0:29:15, Simon Kitching wrote:

 > == discovery
 > Regarding changes to the commons-log "discovery" process, I'm far less
 > convinced. I personally like the fact that commons-logging works fine
 > without any commons-logging-specific configuration. Essentially, a
 > person deploying an application built with commons-logging doesn't need
 > to know that commons-logging is used by the application. They just
 > configure whatever logging library is available in the environment the
 > application is being deployed into, and commons-logging auto-detects
 > that library and uses it.

Ceki Gülcü

   The complete log4j manual:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message