On Sun, 2005-03-20 at 13:49 +1200, Simon Kitching wrote: > 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).
interesting point about contemporary support agreements. in the early days, the consensus amongst ASF folks who did commercial web application deployment (and senior tomcat developers) was that they would never deploy an application as a sealed unit without first unpacking and re-rolling it for deployment. (this is the model proposed in the specification.) i've never really worked in the shrink wrap sector so i'd be interested to hear the opinion of anyone who has in recent times about the current situation... i should probably have caveatted the term advice here. this is a standard recipe handed out when faced with the classic 'help! make JCL work' problem. the people who'd ask this were almost always people who had control of their container and just wanted to get something running. it's no good asking users who just want to get it running what classloading model they are using: they don't know and (for the most part) they don't care. they just want XYZ to run. recommendations for professional deployers should be very different (or deployer who are looking to set up a good production deployment). the documentation doesn't make this clear at the moment. > > 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. FWIW i seem to recall that parent first classloading models emerged in the early days of ejb's from the enterprise (rather than the servlet) side. maybe support for parent first loading models could have been an implicit specification requirement (part of the TCK, say). it may be better to contact someone else. IIRC remy was less heavily involved with tomcat in the early J2EE era. i would suggest craig though costin and jason (hunter) should also have intimate knowledge of the way the early specifications developed. if you decide to try craig, post from your apache address. > > 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. the more i think about it, the more that your material looks like a recommendation and the older like a recipe. i really do think there are two use cases: users who just want to get something running (for development or evaluation, say); and deployers who want to deploy an application correctly (and who are willing to invest the time to understand all the issues). recipes are aimed at the first, recommendations at the second. i also think that we really need to be recommending that deployers think about undeployment. log systems have difficulties during hot deployment. if you aim to hot-deploy a self-contained web application then this should contain appropriate life cycle listeners so ensure that the log system has time to close down correctly. this is also the right time to call release if you use JCL. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
