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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
