commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] commons-logging and j2ee
Date Sun, 20 Mar 2005 08:35:48 GMT
On Sun, 2005-03-20 at 12:12 +1200, Simon Kitching wrote:


> Option 2: have log4j.jar loaded via a "shared" classloader, and have the
> container set up a ContextualRepositorySelector.
> log4j's ContextualRepositorySelector class keeps a Map keyed by
> context-classloader, just like JCL's LogFactory (v1.0.4) does, and hence
> has the same limitation: a memory leak on undeploy unless the component
> or the container explicitly "clears" the configuration when it is
> undeployed. The log4j team get around this issue by *assuming* that the
> container will explicitly implement log4j-awareness. In other words, a
> webapp that uses log4j will not properly integrate with its container
> unless the container is explicitly written to use log4j.
> This issue is exactly the one that JCL 1.0.5 attempts to resolve using
> weak references; log4j just don't bother.

this is probably an example of convergent evolution. log4j has similar
problems to JCL. there are only a small number of solutions to this

(this is one reason why i have been trying to persuade ceki that unless
he wishes to risk looking foolish, he should try harder to avoid
overstating his case when being critical of JCL.)

- robert

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

View raw message