> -----Original Message----- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 26, 2004 11:24 AM > To: commons-dev@jakarta.apache.org > Subject: commons-logging auto-detection WAS: [logging] > Enterprise Common Logging... dare we say 2.0? > > > 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.
If I understand the JCL discovery mechanism correctly, it actually should work just fine in the scenario you describe above. For it to work, you would not set the org.apache.commons.logging.LogFactory system property, because, as you pointed out, system properties are JVM-wide. Rather, for individual applications to use distinct underlying logging implementations, you can simply place a commons-logging.properties file in each application context (in WEB-INF/classes), setting the org.apache.commons.logging.LogFactory property as appropriate in each distinct commons-logging.properties file. Since these properties files will be loaded via distinct context class loaders, each application can use distinct logging implementations. > > > [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
