I believe you have to have code that you know will execute very early in your application(perferably the first thing), and have that call LogManager.getLogManager().readConfiguration(inputstream); where inputstream is for your classpath loggging.properties file.

The problem is to know/have bit of code that does this either first thing (or early enough) in the bootup of your application. Not always easy… it would be nice if this was part of the default behaviour of LogManager.

Where I work we support System.out,err/commons-logging/log4j as different libraries use different logging techniques. (All them end up in Log4j for consistent configuration)

Pure FUD: You can’t half-ass bundle your webapps.

Bundle the app and not the dependencies, leave it to the container and you have no problem and let you customers know that your installation model and it’s chaos. Have fun supporting that, I hope they chose to install the same version of your dependencies as you wanted.

Pick some of your dependencies and hope everything works out for you & getting logging working is half your problem.
I hope whatever random version the client had lying about was the same one you tested and built with.

Package your webapp with exactly what it needs to run and you will no trouble.

This is a real issue you can’t just brush aside and say abstractions are pointless.

Another + for JCL is the simplicity with which you can actually create stub of the Log interface. All the other options require either larger interfaces that are less intuitive (slf4j), or more gymnastics to wire up objects that don’t matter for what you want to test (jul, log4j).

App servers like Tomcat and WebSphere, for example, ship with their own versions of JCL and are configured to use a particular logging implementation (say Log4j or Java Logging API). The problem occurs when you want to deploy a web application into the server that also uses its own JCL library and configures its own logging implementation. Now, because there are multiple classloaders in this environment and multiple JCL libraries and implementations, which JCL will the class loader that loaded your JCL consumer have visibility to? The server JCL or the WAR JCL? It all depends on how you configure your class loading mode at the EAR and WAR levels. If you use the PARENT_FIRST at the WAR level, then the classloader will first delegate the loading of classes to its parent classloader where it will find the server JCL. This is not what you want! If you use the PARENT_LAST at the WAR level, then the classloader will first attempt to load classes in your WAR where it will find your WAR JCL. This is what you want. BUT the problem is that it’s not all that simple. Other class libraries that are deployed at the EAR level could be using JCL too? What class loading mode are they using? If your JCL consumer references one of those classes and the class loader that loads those loads the server JCL then you will have a conflict between the two JCL versions. This is where things blow up. The app server is not able to separate the server/container and application classloaders in a way that does not cause conflicts with the two versions of the of JCL classes. It’s the paradox that is using JCL in a J2EE environment.

Now if you were to replace the JCL in the WAR with the jcl-over-slf4j implementation you would still have the same problem. Like the JCL library being replaced, it too is just another version of JCL classes that will confuse all class loaders.