commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] JCL1 LogFactory incompatibility with WAS
Date Wed, 01 Mar 2006 01:32:45 GMT
On Tue, 2006-02-28 at 22:32 +0000, robert burrell donkin wrote:
> i've downloaded and installed an evaluation version of WAS to try to
> confirm that WAS ships with JCL (and if so, where abouts). 

Great. 

> 
> i also plan to see if i can improve recognition of this situation and
> (if so) provide a better message.
> 
> > It's a variant on the old "xyzLog does not implement Log" issue which
> > the adapters jar was created to solve. JCL is already deployed in a
> > shared path AND a full JCL has been deployed in the webapp. As a result,
> > LogFactory is loaded from the webapp path but the custom LogFactory
> > implementation is loaded from an ancestor classloader and therefore is
> > bound to a different LogFactory implementation. There's no way for us to
> > work around this using classloader tricks as far as I can see; 
> > the adapters jar is the proper solution.
> 
> +1

I guess one thing we *could* do is fall back to using LogFactoryImpl if
the system property points to a class that we can't cast to LogFactory.

That's a pretty scary thing to do though; the application has
*explicitly* set a property to tell JCL which class to use but we ignore
it and use another one instead? What do you think?

> i'll also try to verify that adding the latest JCL to the appropriate
> system classpath also fixes this problem.

I don't believe that will fix this situation.


> > What we *do* need to consider is whether we can improve the
> > documentation or the error messages to make it clear what the correct
> > fix is.
> 
> +1 (see above)

We could test the class to see if it has an ancestor whose *name* is
"org.apache.commons.logging.LogFactory". If it does, then we have
multiple copies of JCL in the classpath and could emit a warning that
commons-logging-adapters.jar should be used instead.

That seems like a good idea to me, so unless someone speaks up quickly
I'll add code to do that.

Cheers,

Simon


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