commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"
Date Sun, 22 May 2005 22:59:55 GMT
--- robert burrell donkin
<> 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. 


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).

>> 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
>> (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.
>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
>>     (or commons-logging-api.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?
>but there is a variation (that i have discussed with
>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
>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
>i think so. maybe brian could repost his link.

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. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message