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 Tue, 28 Feb 2006 22:03:09 GMT
On Mon, 2006-02-27 at 21:19 +0000, robert burrell donkin wrote:
> On Mon, 2006-02-27 at 12:13 +0100, Boris Unckel wrote:
> > Hello,
> 
> hi boris
> 
> > I have tested several other cases, the results and conditions
> > are in the zip.
> > I am really wondering about one case: The delegation mode of all
> > tests is PARENT_LAST, for ear and war.
> > I have put a commons-logging.properties file in the classpath of the EAR and
> > the WAR (each). It still does not work (see subdirectory error).
> > 
> > I will not go further on my own (due to time limitation) but if you have a
> > special testcase or a newer version I will test again.
> 
> thanks for very much for your work - it's very much appreciated :)

It certainly is appreciated; testing is what we most need at this point.
Thanks Boris.

The new diagnostics system appears to be paying off here; the output
shows a lot about what's going in with the "failed" scenario that Boris
provides.

It looks like IBM Websphere 5.1 uses its own LogFactory implementation
rather than the default o.a.c.l.impl.LogFactoryImpl. It appears to set
system "org.apache.commons.logging.LogFactory" to point to class 
  com.ibm.ws.commons.logging.TrLogFactory.

The setup that Boris has used doesn't follow the guidelines in the user
guide for this situation; the container provides JCL, so the webapp
needs to bundle commons-logging-adapters.jar, NOT commons-logging.jar.
See:
http://people.apache.org/~rdonkin/commons-logging/site2/guide.html#commons-logging-adapters.jar


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.

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.

Boris, would you please replace commons-logging-1.1-RC5.jar with
commons-logging-adapters-1.1-RC5.jar in your webapp and retest? This
should solve the problem. It would also be useful if you could try
commons-logging.jar from 1.0.4 with this webapp and verify that a
logging failure occurs.

General comment: the fact that WAS has a custom LogFactory
implementation means that most of the improvements we added to the 1.1
release of JCL won't be available to WAS. The only thing we need to do
is make sure that the changes we made to the base LogFactory abstract
class haven't made anything *worse*. I'll review the changes to
LogFactory.java to see if there are any implications for custom
implementations. Maybe the user guide could do with a note about the
fact that WAS uses a custom LogFactory implementation....


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