Date: 2004-10-31T04:15:42 Editor: HenningSchmiedehausen <[EMAIL PROTECTED]> Wiki: Jakarta Commons Wiki Page: Commons Logging FUD URL: http://wiki.apache.org/jakarta-commons/Commons Logging FUD
no comment New Page: Commons Logging FUD If you take a look at commons logging, you will sooner or later meet the various pages that recommend '''not to use commons-logging'''. You know whose pages these are, as examples, here are a few: [https://www.qos.ch/logging/thinkAgain.html Think again before adopting the commons-logging API] [http://jroller.com/page/fate/20040727 Commons-logging revisited] (The language of this article might reflect on the author) However, if you look closer at these rants, you will notice, that everything boils down to a single phrase: "class loader problems". Class loader problems are commons-logging's fault? Hardly. It is the mixture of a popular project, some unfortunate class loader decisions and the rants of people who might not understand all the implications of the web container class loaders. If you look at the [http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html Tomcat 5 class loader reference], you will notice that commons-logging-api.jar was put into the bin/ directory and is available through the System classloader. That was the unfortunate decision. The same issue happens BTW with common-daemon. Why does noone complain? Maybe because it is not such a popular project? So the class loading sequence is * Bootstrap classes of your JVM * System class loader classses (described above) * /WEB-INF/classes of your web application * /WEB-INF/lib/*.jar of your web application Look at the second point. That is the source of the pain. But there is easy relief. The documentation of the ''Catalina'' class loader states: Catalina - This class loader is initialized to include all classes and resources required to implement Tomcat 5 itself. These classes and resources are '''TOTALLY invisible to web applications'''. All unpacked classes and resources in $CATALINA_HOME/server/classes, as well as classes and resources in JAR files under $CATALINA_HOME/server/lib, are made visible through this class loader. That is what we want, isn't it? Do the following thing in your $CATALINA_HOME: mv bin/commons-logging-api.jar server/lib and in the $TOMCAT_HOME/bin directory, there are two scripts which reference commons-logging-api.jar directly: catalina.sh and catalina.50.sh (or the respective .bat files for Windows). Replace the "$CATALINA_HOME"/bin/commons-logging-api.jar with "$CATALINA_HOME"/server/lib/commons-logging-api.jar. That's it. Now commons-logging is completely invisible to you application. Of course, if your application relies on this library being in the system classloader, it will now crash with a ClassNotFound exception. Relying on a such a library is a bad idea anyway, you should ship such a library with your web app. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
