On Wed, 2006-03-01 at 11:03 +1300, Simon Kitching wrote: > 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.
+1 :) > 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. +1 > 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 i've downloaded and installed an evaluation version of WAS to try to confirm that WAS ships with JCL (and if so, where abouts). 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 AIUI (haven't verified this as yet) IBM uses a system property to specify the LogFactory implementation so JCL will work fine if the administrator specifies the standard implementation on the command line. i'll also try to verify that adding the latest JCL to the appropriate system classpath also fixes this problem. > 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) i have some more material already prepared for the troubleshooting document but nothing IBM specific. any volunteer to create a patch? <snip> > 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.... +1 WAS uses the factory to bridge to it's standard logging system. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
