Couldn't this be refined even further by incorporating a change to JCL I proposed earlier? Here's a copy of my original post: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 have an idea... All logging implementations for Java configure logging by package, right? What if we allow component developers to include their own commons-logging.properties 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 commons-logging.properties 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 commons-logging.properties 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.
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorManager.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
