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.
[1] http://wiki.custine.com/display/ENV/Log4j+1.3+and+Tomcat5 [2] http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ [3] http://www.qos.ch/logging/sc.jsp
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: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
