commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Date Mon, 27 Dec 2004 20:49:30 GMT
Martin Cooper <mfncooper@gmail.com> wrote on 12/27/2004 01:07:28 PM:

> On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze <rsitze@us.ibm.com> 
wrote:
> > Ceki Gülcü <ceki@qos.ch> wrote on 12/27/2004 05:49:45 AM:
> > 
> > > At 03:05 AM 12/27/2004, Charles Daniels wrote:
> > >
> > > >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.
> > >
> > > Good point. This will require some understanding by the user about 
the
> > > classloader delegation mechanism used by the app server, which 
varies
> > > from vendor to vendor or even from version to version of an app 
server
> > > by the same vendor.  Nevertheless, I stand corrected.
> > 
> > I wish :-(
> > 
> > In fact, this works ONLY if JCL is *not* available in a "common"
> > classloader higher up the hierarchy.  In that case, the config file
> > packaged in commons-logging.jar is found and used.
> > 
> > If JCL *is* packaged as a shared library in a parent classloader, then 
the
> > work around is typically a non-standard feature offered by some J2EE
> > hosts, for switching the search order within the classloader hierarchy
> > from parent first to parent last.  This allows the config file 
packaged
> > with the app to be located first.
> 
> I think you have this backwards. The standard J2EE class loader lookup
> order is local first and then parents (i.e. parent last), as opposed
> to the standard Java 2 order, which is the reverse. The non-standard
> feature provided by some containers is to use the Java 2 order instead
> of the J2EE order. See:
> 
> http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

Excellent point.  However, these are recommendations, not requirements. 
The problem, as described, is real enough.  Also, more importantly, I tend 
to use J2EE to demonstrate the issues surrounding more sophisticated 
ClassLoader hierarchies, but it should never be assumed that it is the 
only one.

We all agree that the problem is real enough in various environments.

> --
> Martin Cooper
> 
> 
> > Part of the proposal for "new discovery" is to circumvent the 
classloader
> > hierarchy [at a cost] and for picking up configs from the lowest point 
in
> > the hierarchy.
> > 
> > >
> > > --
> > > Ceki Gülcü
> > >
> > >    The complete log4j manual: http://qos.ch/log4j/
> > >
> > >
> > >
> > > 
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > 
> > *******************************************
> > Richard A. Sitze
> > IBM WebSphere WebServices Development
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message