commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Jaynes <>
Subject Re: [logging] components at server and web app levels
Date Wed, 08 Oct 2003 13:50:40 GMT
Thanks for the reply, but I don't see how it relates to my problem. I'm 
not trying to consolidate my log files in one place. The problem is 
that, if your web applications use compenents that use commons-logging, 
commons-logging evidently causes a de facto requirement that any 
components that use commons-logging can't be deployed at the app server 
level, but *must* be in the WEB-INF/lib of each web application.

Here's an example of what can go wrong:
I have slide and HttpClient in resin/lib. HttpClient uses 
commons-logging, so I have to add commons-logging to resin/lib. My web 
app uses Struts, so I've got commons-logging in WEB-INF/lib, and I use 
log4j, so log4j.jar is also in WEB-INF/lib. (by the way, I'm using Java 

As soon as my web app trys to use HttpClient I get a "Class 
org.apache.commons.logging.impl.Log4JLogger does not implement Log" 
exception. I believe that what is happening is this: HttpClient loads 
with the server classloader. It then loads LogFactory and LogFactoryImpl 
with the server classloader. LogFactory specifically uses the thread 
context classloader to look for log4j. The thread context classloader is 
the web app's classloader, so it finds log4j and then loads Log4JLogger, 
but it is still using the thread context classloader, so it finds the 
Log4JLogger in the WEB-INF/lib. It then does a check with 
Log.class.isAssignableFrom() on Log4JLogger, but since Log and 
Log4JLogger were loaded with different classloaders the test fails and 
the exception is thrown.

After a lot of experimentation, the only configuration of jars that 
works is to put everything in the WEB-INF/lib of each web app. 
Commons-loggin has made it impossible to deploy slide and HttpClient at 
the server level.


Ramsay, Nigel wrote:

> We have also had similar issues. We're using Weblogic for our app server,
> and we also have a number of stand-along services that run in separate VMs
> and with differing classloaders. We use a combination of commons-logging and
> log4j.
> Our solution was to centralise the logging in one place. Each of the
> different VMs, etc then send their logging messages over some kind of
> network transport (in our case, we're using JMS) to the central logging
> service. Another option would be to use the SocketAppender. 
> The implication of this is that you have to configure each VM, etc to point
> to your central logging server. 
> I hope this helps. I know that getting J2EE servers to log sensibly can be
> quite a mission.
> Nigel.
> -----Original Message-----
> From: Will Jaynes []
> Sent: Wednesday, 8 October 2003 3:01 a.m.
> To: Jakarta Commons Users List
> Subject: [logging] components at server and web app levels
> It seems to me that commons-logging has lead me into a classloader 
> quagmire. In a J2EE environment (I use Resin) how can different 
> components that use commons-logging be deployed at different levels of 
> the app server without problems? I can't find a way to centralize, at 
> the  server level, any components that make use of commons-logging.
> Example: I need to use Slide which uses HttpClient which uses 
> commons-logging. These are used in most of my web apps, so I feel they 
> should be deployed at the server level in resin/lib. But my web apps use 
> Struts which uses commons-logging also. And my own web app classes just 
> use log4j straight up.
> I haven't been able to find any combination of jars-in-libs that works, 
> except putting all jars in the WEB-INF/lib.
> The problem seems to come down to the fact that the classloader that 
> loads the LogFactory class may not be the same as the thread context 
> class loader that LogFactoryImpl uses to find the default logging 
> implementation (in my case, Log4j) But I'm waaay out of my comfort zone 
> of knowledge.
> So... Is it possible to use some components that use commons-logging at 
> the server level, and yet still use other components that use 
> commons-logging in a web app?
> Will
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> This communication is confidential and may contain privileged material.
> If you are not the intended recipient you must not use, disclose, copy or retain it.
> If you have received it in error please immediately notify me by return email
> and delete the emails.
> Thank you.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message