commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From commons-...@jakarta.apache.org
Subject [Jakarta Commons Wiki] Updated: Commons Logging FUD
Date Sun, 31 Oct 2004 12:38:21 GMT
   Date: 2004-10-31T04:38:21
   Editor: HenningSchmiedehausen <hps@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


Mime
View raw message