commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] a candidate explanation for "Log4JLogger does not implement Log"
Date Sun, 08 May 2005 05:27:40 GMT
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"

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

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.



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

View raw message