Martin Cooper <[EMAIL PROTECTED]> wrote on 12/27/2004 01:07:28 PM: > 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
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: [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] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
