--- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching > wrote: > > Hi All, > > > > I've been working for quite a while now to try to > figure out why users > > of JCL have been getting the "Log4JLogger does not > implement Log" > > message. > > > > I think I've finally really understood the cause. > If this is really > > obvious to everyone, please let me down gently :-) > > one thing which i have learnt from working with JCL > over the years is > that nothing is ever obvious :) > > more than anything we need clear explanations of > what happens and why. >
+1. I understood (and had since forgotten) from working with Ceki Gulcu's JCL analysis that the problems happened when code loaded a parent loaded tried to log with the TCCL in effect, but your discussion of why such a call would be made -- outside a test fixture :) -- makes the real world issue much clearer (and easier to remember). <snip> >> Ok, so what is the solution? > > >i would like to split this question into two. > > >i believe (as indicated in the analysis document) that the correct >behaviour in these cases is for JCL to recognise that log4j is not >viable (for this configuration) and default to java.util logging. this >is a little unsatisfactory but i don't see a reasonable technical >solution for these configuration. > One unsatisfactory aspect is that instead of throwing an exception with a nice message and stack trace, logging would mysteriously be done using an unexpected logging library. But Simon's recent work on adding diagnostics should help mitigate this drawback. > >the other question (which i think is what simon addresses below) is how >can JCL provide a solution for a user who needs a similar configuration >but who is willing to choose to deploy JCL slightly differently. > > >> (1) >> Well, ensuring that the logging adapters are deployed via the parent >> classloader *only* is one. That fixes the problem, as Log4JLogger et. >> al. always bind to the same Log interface that LogFactory binds to. >> >> The downside is: >> * It means that the logging library must also be deployed via the >> parent classloader, even when there *are* no other classes in the >> parent classloader that trigger this problem (ie ones that use JCL >> and that the webapp is going to call into). >> >> Having the logging library loaded via the parent classloader means >> that dumb logging libraries may not be able to find their config >> files. >> >> Some logging libs may be smart enough to look for their >> resource files via the context classloader. And in some cases the >> logging *adapter* class might be able to tell the logging lib >> where the config file is. Assuming we can rely on (or trick) the >> logging lib to correctly handle per-context-classloader location >> of their config files, all should be well. > > >-1 > >seems like giving away too much for a corner case > > >> (2) > I think we could simply change the distribution bundles. The root >> problem appears to be to me that the adapters (Log4JLogger et al) are >> bundled with a Log implementation. If we produced a jar that included >> Log4JLogger et al. but *without* the Log class, the problem should be >> solved. The rule would then be: >> * if the parent loader has commons-logging.jar or >> commons-logging-api.jar, then deploy >> commons-logging-adapters.jar in the child, together with the >> actual logging library. >> * otherwise, deploy commons-logging.jar in the child >> (or commons-logging-api.jar + commons-logging-adapters.jar) > > >this approach to these kinds of configuration is the one i was thinking >of earlier when i suggested that we might need an implementations only >distribution. a reasonable user could then adjust the deployment so that >the implementations were in the child and the api in the parent. > > >> (3) >> Maybe we should just do away with LogFactoryImpl's attemp to load a log >> adapter via the context classloader. It does enable the setup of having >> commons-logging-api.jar in the parent and commons-logging.jar in the >> child, but it fails badly if any other class in the parent classloader >> uses JCL and is called by the webapp. Is this benefit worth the pain? > > >no > > >but there is a variation (that i have discussed with richard >previously). the particular problem situation can be diagnosed (a log >class loaded from the context should have an incompatible classloader). >when the implementation is not viable, rather than throw an exception >JCL could try to load the class with the same name from it's >classloader. > > >i think that brian's patch does something which though implemented >differently has the same net result. > > >however, i don't think that either of these approaches would actually >work in this case: log4j is not visible to the parent classloader. i do >think that something along these lines will be needed for the exotic >classloader configurations (which haven't been analysed yet). > > >> BTW, Brian proposed a splitting-up of the JCL jars a few months ago, as >> experiments showed it resolved some issues. I can't find the emails just >> now. Is it related to the solution (2) proposed above? > > >i think so. maybe brian could repost his link. > http://xnet.wanconcepts.com/jcl/furtherAnalysis.html Yes, definitely related. Sorry, Simon. When I read your original post I missed this question, or would have replied long ago. - Brian __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
