commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: commons-logging & classloading
Date Fri, 10 Oct 2003 17:06:13 GMT
Will Jaynes wrote:

> I was hoping some developers would weigh in on this issue. I expect that 
> this has been discussed before, but I can't find any references.
> I believe the classloading in commons-logging is broken. The web app use 
> case I describe below is a demonstration of why c-l is broken. The way 
> classloading is implemented makes it impossible to to share components 
> at the J2EE server level. It's clear from looking at the 
> LogFactory.getContextClassLoader() method that the developers explicitly 
> want to use the thread context classloader. But it just causes problems.
> I went in and changed LogFactory.getContextClassLoader() to simply 
> return LogFactory.class.getClassLoader(), and all my logging problems 
> went away. I can put slide, HttpClient, commons-logging at the server 
> level; and struts, commons-logging, log4j in the web apps. And things 
> work fine and just as I expect them to.
> So, can someone please explain why commons-logging is implemented as it 
> is? Will anyone consider changing it?

I believe the current commons-logging implementation is just fine. 
However, containers which use it (such as Tomcat) must include it in a 
very specific way to have it work fine in all situations. I believe you 
won't experience any problems with Tomcat 5.

The way to use it is what you say: place your logger, its configuration, 
as well as the commons-logging logger plugin (or the full JAR, as you 
wish) in your /WEB-INF/lib.


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

View raw message