On Sat, 2005-03-19 at 23:12 +0000, robert burrell donkin wrote: > On Sat, 2005-03-19 at 01:32 +1300, Simon Kitching wrote: > > The commons logging wiki FAQ page > > (http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions) > > has this: > > > > <extract> > > == Log4JLogger does not implement Log == > > > > {{{ > > I have an exception with message 'Log4JLogger does not implement Log'! > > What's the cause and how can I fix this problem? > > }}} > > > > This almost always a classloader issue. Log has been loaded by a > > different classloader from Log4JLogger. Please ensure that: > > > > * all the logging classes (both Log and the logging implementations) are > > deployed by the same classloader > > * there is only copy of the classes to be found within the classloader > > hierarchy. In application container environments this means ensuring > > that if the classes are found in a parent classloader, they are not also > > present in the leaf classloader associated with the application. So, if > > the jar is deployed within the root classloader of the container then it > > should be removed from the application's library. > > </extract> > > IIRC this is standard advice given scores of times over the years
This advice says that when deploying a commercial webapp purchased from company X, the deployer should unbundle it and delete commons-logging.jar from the WEB-INF/lib. This is hideously ugly, probably violates the support agreement for that commercial product, and isn't necessary (as long as standard child-first classloading is being used). > > i'm working on a more detailed troubleshooting document for inclusion in > the standard distribution. (another reason why i haven't rolled another > release candidate.) > > my intention is to pull together various simple recipes (similar to that > given in the wiki) that have helper users over the years and add in more > detailed advanced sections that give some help on the more complex cases > where classloaders have to be considered. That's a fine idea. I've been trawling all over the internet it seems in order to gather exactly this information myself. I'd be very keen to proofread and contribute to such a document. > > i'm also working on demonstration code inspired by ceki's but > approaching the issues more systematically. i see these two approaches > working in tandem. i've started with the parent first cases. i may > publish when they are finished. Great. By the way, despite reading a significant amount of documentation and code for various containers and posting to a number of email lists, I have found absolutely ZERO information on *why* some containers provide a parent-first option at all. Even tomcat does so (<loader delegate="true"/>) but doesn't document why this feature is provided, and Remy Maucherat (who appears to be the author) hasn't responded to my email. > > change the wiki if you wish (perhaps considering retaining the recipe in > some form). alternatively, you could wait for the troubleshooting > document. Ok, I'll try to come up with something that keeps the old (simple) advice as well as my proposed text. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
