commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: JCL problems
Date Mon, 14 Feb 2005 12:14:17 GMT

Robert,

I am a bit surprised by your question. As the current release manager
for JCL, I suppose that you are aware that LogFactoryImpl only uses
the thread context class loader (TCCL) to search for classes. You were
aware of that, weren't you?  In theory, this is supposed to let a copy
of commons-logging.jar placed in a parent class loader to discover
another logging API, say log4j, whose classes are visible to a child
class loader with the child loader also set to be the TCCL. However,
this dynamic discovery does not work. The copy of log4j.jar must be
placed next to commons-logging.jar.  Moreover, the copy of
commons-logging.jar must be placed very high in the class loader tree,
say in the system class loader or the application server's class
loader, but that is not all. There must not be other copies of
commons-logging.jar in war files of web-apps.

To cut a long story short, do to anything meaningful reliably, JCL is
a lot more complicated to set and even when set up "correctly" brings
no benefits when compared to static API binding as found in UGLI.

I urge you run though the examples in [1] which should demonstrate to
you how badly and irreparably JCL is broken. The source code is all
there. Even if you don't trust my opinion, at least trust your java
compiler and your JVM.

[1] http://www.qos.ch/logging/classloader.jsp

At 08:50 PM 2/13/2005, robert burrell donkin wrote:
>(i'm not sure whether i'm missing your point.)
>
>it seems to me that it matters not whether the discovery is dynamic or
>static: the log4j library needs to be available in the classloader.
>static discovery would break in a similar fashion if a required library
>is not present.
>
>from a practical perspective, i don't really see having to put a number
>of libraries together so that they are loaded by the same classloader is
>really a restriction. what matters is that there are ways to achieve the
>required results and definite instructions are available which are easy
>for deployers to understand.
>
>- robert

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



---------------------------------------------------------------------
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