commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: logging: more then one version of 'org.apache.commons.logging.Log'
Date Thu, 10 Nov 2005 08:19:15 GMT
On Wed, 2005-11-09 at 09:17 -0500, Keith Naas wrote:
> Question:
> The LogFactoryImpl loads the interface on the ClassLoader from
> LogFactoryImpl.getClass().getClassLoader().  However, it loads the
> implementation on the Thread.currentThread().getClassLoader().  Why does
> it use two different ClassLoaders instead of loading both the interface
> & implementation on the same ClassLoader? 

It's quite deliberate. This is so the commons-logging.jar can be in some
"shared" classpath, as it is in tomcat for example, but the adapter
class and the concrete library can be bundled in a webapp.

If webapp X wants to use Avalon logging, it should not be necessary to
put the avalon.jar file in the server classpath; that lib should go in
WEB-INF/lib of the webapp. However in this case, the logging "adapter"
class for commons logging ("the implementation" you refer to above)
needs to be loaded via the same classloader as the underlying logging
lib in order to be able to access its classes.

Now if JCL is deployed in an ancestor classloader, then the JCL
LogFactory class is expecting to cast the adapter object to an
implementation of the Log interface - one loaded via the same
classloader as the LogFactory.

And this leads unfortunately into a very tangled web of classloader

Having the logging libs in the webapps also ensures that logging config
is separate for each webapp, by forcing separate class instances to be
used for each webapp; many libs will fail in very interesting ways when
deployed in a container classpath and used by multiple webapps
simultaneously. And of course it allows different versions of the
logging lib to be used concurrently.

May I suggest you try the current HEAD JCL version? Several of us put
quite a lot of effort into trying to resolve as many issues as possible
within the constraints of the existing design. And there has been an 
effort to avoid hard failures (throwing LogException) where there is any
kind of halfway acceptable fallback that could be made. The end solution
isn't perfect, but hopefully it's better than JCL 1.0.4. However there
are so many different containers and different uses of them out there
that only people like you can really tell us whether the changes are for
the better.



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

View raw message