logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Taxonomy of JCL problems
Date Wed, 09 Feb 2005 19:34:22 GMT
At 05:46 PM 2/9/2005, Niclas Hedhman wrote:
>On Wednesday 09 February 2005 23:34, you wrote:
> > As you are very knowledgeable in class loader
> > problems, I'd appreciate your comments and/or critical reviews.
>First of all, I am very happy to see that someone else care, and care to such
>an extent and goes through all the pain to explain this to everyone to such
>detail. There are some minor mistakes, like
>Class loading problems encountered when using JCL fall into two main


>JCL has been a favourite hate-object of mine for quite a long time, and I am
>surprised that it is still around and even seems to gain popularity... :o(

It's both surprising and fascinating at the same time.

>But, the same problem as exists with the JCL <-> Log4J relationship, exist
>between "Log4J core" <-> Appenders (e.g.), although at a much smaller scale.


>The Appenders must be loaded by the same classloader as Log4J, and that being
>at start-up.
>This is basically the same requirement that exist in JCL as well.
>this API must be located at the same level or higher in the class loader tree.

Yes and no. JCL's discovery mechanism (surprisingly enough) stands in the 
way of several configurations which otherwise would have been possible by 
just breaking up the core and the extensions. Log4j 1.3 is broken into 
several pieces allowing log4j extensions and their dependencies to reside 
in child class loader while log4j-core resides at the same level or higher 
up. Unfortunately, log4j tries to load appender through the TCCL, a 
practice that can be euphemistically qualified as "problematic".

>In relation to JCL, you can argue that both containers and webapps uses both
>JCL and Log4J so the problem is extremely common, whereas "my scenarios" are
>less common, but in fact the same issue, that being that blindly loading
>classes from java.lang.String is not a good practice and a ClassLoader
>argument should be provided in such contexts.

Whoa. That's a big paradigm shift.

>It is also necessary to have a proper API/Impl split, and basically push the
>impl classes as far down as possible (out of view) and keep the stable API
>classes higher up and shared.


>If I use UGLI's ULogger interface I can do this, push the API (ULogger) high
>up and push the implementation(!) (Log4J) far down, then Log4J needs to be
>treated as a big blob of implementation, with stuff like the mail.jar as a
>real dependency, since configuration changes in running servers, could later
>include SMTPAender and crash (have not checked how severly lately, but used
>to be pretty badly.).

This problem "fixed" in 1.3. The current solution is not entirely 
satisfactory because it relies on the TCCL.

>Now, I don't like to treat Log4J as a static monolithic blob of
>implementation, but ATM I have no choice. But this could change, and Log4J
>become a more dynamic creature, capable of adapting in non-stoppable servers.
>If a proper plugin model is employed for all things that are loaded
>dynamically through the configuration files, all this could be solved (not
>the JCL mess!)
>That would basically mean that the configuration specified a "plugin URI",
>which described the resources needed to load the plugin into Log4J, and Log4J
>managed the loading and unloading of those. That is what we do in DPML
>(http://www.dpml.net) for just about everything, and is not that hard. Log4J
>ends up being a 'big monolithic blob of implementation', but that is far from
>Unfortunately, the solution we have, called Transit, requires JDK1.4 and not
>generally available to Log4J, but something similar should be developed here.
>Current API and impl of our plugin system can be found here;
>if you want to study what we have done.
>The StandardLoader uses a properties file to understand the plugin structure,
>esp what are API resources and what are the Impl resources. Find attached (if
>it goes through the mailing list) such descriptor for the Log4J provider in
>our logging system. (Note; this plugin does not define any API resources)

Before trying out more sophisticated approaches, I'd like to ascertain that 
the approach adopted in 1.3 does not work. I currently don't have the time 
to devote more time to this topic in any more depth.

>Hope I didn't bore everyone to death :o)

On the contrary.

>P.S. The paragraph that was just added about UGLI doesn't have these kinds of
>problems doesn't convince me at all. If you bundle JCL with Log4J similarily
>to how you bundle UGLI+Log4J, wouldn't the same be true for JCL?

Bugs of Type-I would be solved but JCL also suffers of Type-II even if 
log4j and JCL are bundled together.

>I don't see
>anything dealing with classloaders...just like in JCL. I understand why it
>doesn't, but I don't understand how you claim there is a difference in this
>respect (except for the hash table).

Unless the ugli-xxx.jar file is corrupt, UGLI cannot never cause bugs of 
Type-I, Type-II or Type-III for the simple reason that all the required 
files are bundled together in the ugli-xxx jar file. UGLI's LoggerFactory 
only uses the class laoder that loaded LoggerFactory itself to instantiate 
other classes. In future versions of UGLI, the binding will done at compile 
time, so such questions won't even need to be asked.

Ceki Gülcü

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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message