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 Mon, 09 May 2005 21:01:23 GMT

--- Simon Kitching <skitching@apache.org> wrote:

> On Sun, 2005-05-08 at 01:06 +1200, Simon Kitching
> wrote:
> > Ok, so what is the solution?
> > 
> 
> > (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)
> 
> Hmm..this approach might aggravate the "memory leak
> on webapp reload"
> issue.
> 
> To recap, the LogFactoryImpl holds a map of
> (logger-name, log). If those
> log objects belong to a class loaded from the child
> classloader then
> they hold references to the child classloader. This
> prevents the
> LogFactory's (weak-ref-to-classloader,
> strong-ref-to-logFactoryImpl) map
> from freeing stuff related to a classloader, as
> there is a strong ref to
> the context-classloader via
>
LogFactory->LogFactoryImpl->Logger-class->classloader.
> 
> Recommending that commons-logging-api.jar be in the
> parent, but
> commons-logging-adapters seems to be exactly the
> scenario to trigger the
> unfixable-via-weakrefs leak :-(.
> 
> I haven't proved this, and it's complicated enough
> that I might be wrong
> here. But I thought I should mention it now.
> 

Nope, sadly I'm quite sure you're right.

Bug 31286
(http://issues.apache.org/bugzilla/show_bug.cgi?id=31286)
has a unit test patch that simulates a "parent has
api, child has adapters" classloading scenario.  It
fails with a memory leak.

Haven't had a chance to digest your recent postings,
so apologize for not giving more feedback.

Brian

> 
> Cheers,
> 
> Simon
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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