commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <bes_commons_...@yahoo.com>
Subject Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"
Date Sun, 22 May 2005 22:59:55 GMT
--- robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message