commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <>
Subject Re: commons-logging auto-detection WAS: [logging] Enterprise Common Logging... dare we say 2.0?
Date Mon, 27 Dec 2004 19:26:36 GMT
Ceki Gülcü wrote:
> 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 file
>> in each application context (in WEB-INF/classes), setting the
>> org.apache.commons.logging.LogFactory property as appropriate in each
>> distinct 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.
Couldn't this be refined even further by incorporating a change to JCL I 
proposed earlier?  Here's a copy of my original post:

I have an idea... All logging implementations for Java configure logging 
by package, right?  What if we allow component developers to include 
their own that's not at the root of the 
source tree?  For example, if Morph suddenly decided it was very 
important to have certain messages logged, I just drop a in net.sf.morph that specifies the logging 
settings for net.sf.morph and all subpackages (e.g. which log factory to 
use, whether my messages *must* be heard, etc).  If JCL detects such a 
file it ensure the component that the logging it specifies is happening. 
  If an application developer, assembler or deployer decides later that 
Morph really isn't as important as I'd like, then they just delete the or put their own version in the 
WEB-INF/classes directory.  (Forgive me if this is a great show of my 
ignorance of classloading, but I think this is at least how things work 
for Tomcat).

Searching for a file like this on the classpath would certainly have 
performance implications.  However, search cost is incurred only on 
startup and there is precedent (see below), so it can't be too bad. It's 
certainly worth a try.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message