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. 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]
