tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Why commons-logging-api.jar?
Date Thu, 24 Apr 2003 19:26:04 GMT
Craig R. McClanahan wrote:

> On Thu, 24 Apr 2003, Costin Manolache wrote:
>> What doesn't work is having log4j.jar in a child loader, and
>> log4j-commons-logging in a parent loader. That's because classes in
>> log4j-commons-logging are using log4j classes.
> Won't this still work if the code in log4j-commons-logging uses the Thread
> context class loader to load the Log4J classes?  That will pick up the
> Log4J classes from the webapp, if they are there.

Tried that - doesn't work.

The code in log4j-commons-logging uses log4j classes directly - there is 
a Category field, etc. We could use introspection instead of using the log4j
API directly - but that would slow everything down. 

> I recently added a bunch of unit tests in commons-logging to explore the
> various class loader scenarios, and it appears to me that the Log4J
> adapter in commons-logging.jar should now work correctly in a multi class
> loader environment, with Log4J in either the child class loader or the
> same class loader.

I'll try this. 

Have you run the tests with JDK1.3 too ? I never got it to work - when
Log4JLogger is loaded, it is loaded from the parent loader, and it needs the
fields - of type org.apache.log4j.Logger, which are not in the same loader.

At least at the time I tried this, the class loader that loads Log4jLogger
couldn't figure out that it has to use the thread loader.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message