You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by co...@jakarta.apache.org on 2004/10/31 13:38:21 UTC
[Jakarta Commons Wiki] Updated: Commons Logging FUD
Date: 2004-10-31T04:38:21
Editor: HenningSchmiedehausen <hp...@intermeta.de>
Wiki: Jakarta Commons Wiki
Page: Commons Logging FUD
URL: http://wiki.apache.org/jakarta-commons/Commons Logging FUD
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,19 +1,19 @@
-Commons Logging FUD
+= 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)
+ * [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".
+However, if you look closer at these rants, you will notice, that much 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?
+The same issue happens BTW with common-daemon. Why does no one complain? Maybe because it is not such a popular project?
So the class loading sequence is
@@ -24,16 +24,23 @@
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.
+'''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:
+Looks like what we want, doesn't it?
-mv bin/commons-logging-api.jar server/lib
+First, move the jar out of the System classloader:
+
+mv $CATALINA_HOME/bin/commons-logging-api.jar $CATALINA_HOME/server/lib
+
+Secondly, in the $CATALINA_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 references with "$CATALINA_HOME"/server/lib/commons-logging-api.jar.
+
+commons-logging is now removed from the System class loader but still available through the Catalina class loader. However, as you had to add it to the CLASSPATH in the catalina startup files, it is also available through the root class loader (because it is in the CLASSPATH). This is unfortunate, but no problem because you can override this with dropping your desired commons-logging jar into WEB-INF/lib.
+
+Finally, let me quote another commons-logging advocacy page which sometimes is used as an indicator that even its author considers commons-logging a bad idea. In the words of Rod Waldhoff, one of the inventors of commons-logging (on [http://radio.weblogs.com/0122027/2003/08/15.html his weblog]):
+
+The purpose of Commons Logging is ''not'' to isolate your code from changes in the underlying logging framework. (That's certainly easy enough to do on your own, and not really worth doing in the first place given the ease of switching from one logging framework to another.) The purpose of Commons Logging is ''not'' to somehow be more useful than actual logging frameworks by being more general. The purpose of Commons Logging is ''not'' to somehow take the logging world by storm. In fact, there are very limited circumstances in which Commons Logging is useful. If you're building a stand-alone application, don't use commons-logging. If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging. If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you.
-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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org