commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Jonker" <todds...@speakeasy.net>
Subject Re: commons-logging & classloading
Date Mon, 13 Oct 2003 17:54:13 GMT
Will, what I suggest is placing c-l.jar in your server-level classpath, or in the JVM classpath...
and **nowhere else**.  If you have any custom Logs or LogFactory or anything put that in the
same place.  Then you can be sure that each web-app will use the same classes.

This is what I am currently doing.  I have code USING c-l at both the server level and at
the app level, and it all works fine.

Putting the same jar at the server level *and* at the web-app level seems to be asking for
trouble.

.T.

> -----Original Message-----
> From: Will Jaynes [mailto:jaynes@umich.edu]
> Sent: Monday, October 13, 2003 03:14 PM
> To: 'Jakarta Commons Developers List'
> Subject: Re: commons-logging & classloading
> 
> 
> 
> Remy Maucherat wrote:
> 
> > 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.
> > 
> > Remy
> 
> Remy, This how I've handled things up to now. But now I would like to 
> use HttpClient, which uses commons-loggin. Are you saying that the 
> proper way to handle components that use commons-logging is to put them 
> in WEB-INF/lib; that all such components can not be shared at the server 
> level?
> 
> Will
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 



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