On Mon, 27 Dec 2004 12:41:56 -0600, Richard Sitze <[EMAIL PROTECTED]> wrote:
> Ceki G�lc� <[EMAIL PROTECTED]> 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

--
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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to