On Sun, 2005-03-20 at 12:12 +1200, Simon Kitching wrote: <snip>
> 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 problem. (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
