Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of
 robertburrelldonkin@blueyonder.co.uk designates 195.188.213.7 as permitted
 sender)
Subject: Re: [logging] JCL1 LogFactory incompatibility with WAS
From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <1141176765.3816.72.camel@localhost.localdomain>
References: <29039.1141038836@www083.gmx.net>
	 <1141075189.5080.39.camel@knossos.elmet>
	 <1141164189.3816.23.camel@localhost.localdomain>
	 <1141165963.8528.12.camel@knossos.elmet>
	 <1141176765.3816.72.camel@localhost.localdomain>
Content-Type: text/plain
Date: Wed, 01 Mar 2006 23:06:53 +0000
Message-Id: <1141254413.5033.53.camel@knossos.elmet>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2006-03-01 at 14:32 +1300, Simon Kitching wrote:
> 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 have WAS installed and running. the problem can be replicated on the
latest version. more later.
 
> > 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?

IMHO the container has decided, not the application :)

the application has decided to use JCL or more likely has decided to use
a library which uses JCL.

throwing an exception means that JCL requires that the application be
unzipped and restructured before the application will run in that
particular container. this seems a bit of an overreaction if the
standard implementation is available.

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

sorry: rushing and didn't explain myself fully.

removing JCL from the jar and putting JCL ahead of the IBM classes in
the classpath should (i believe) ensure that the latest JCL version will
run together with the IBM factory (given the specified setup). 

using the adapters jar should result in whichever older version of JCL
websphere ships with being used instead. 

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

+1

logging the classloader used to load that class would be very useful

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org