Simon, I spent some time last night looking at this, mostly just familiarizing myself with how beanutils works so I could understand the problem.
I think you're right to be concerned about JCL, as from what I can see the two applications are very similar: "weak-keyed" map (aka "WeakMap") held statically by class loaded by container (beanutils: BeanUtilsBean.beanByClassLoader; JCL: LogFactory.factories). WeakMap key is the TCCL. WeakMap value is a class loaded by container, but value is instantiated while component loader is the TCCL (beanutils: BeanUtilsBean; JCL: LogFactoryImpl). WeakMap value holds another map (aka "StrongMap") (beanutils: BeanUtilsBean.convertUtilsBean.converters; JCL: LogFactory.instances) StrongMap value is a class loaded by the component loader (beanutils: FloatConverter; JCL: Log4jLogger). Class implements an interface loaded by the container loader (beanutils: Converter; JCL: Log). This reference is likely what's preventing release of the classloader in beanutils. I noticed that the JCL unit test I wrote for memory release has a weakness in that it doesn't add the Log instance to LogFactoryImpl.instances. I noticed that a week ago and added the required call so I could check the tests still passed. They did. But, didn't get a chance to clean up the code and submit a proper patch for the tests. My bad :( I'll for sure do that tonight, plus add some more assertions like the beanutils test has in order to ensure that classes are being loaded by the intended loader. This should either surface a problem in JCL or help shed some light on the beanutils problem. Regards, Brian --- Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi, > > I've just added a unit test > o.a.c.beanutils.converter.MemoryTestCase. > This test case currently fails, demonstrating (I > believe) that there is > a serious memory leak in beanutils in j2ee-like > environments when > components are "undeployed". > > The tests show that if a Converter is registered > while > Thread.getContextClassLoader is set to a > component-specific classloader, > then when the component is "undeployed" that > classloader cannot be > garbage-collected. > > The problem is: I can't spot what is *causing* this > bug. It would be > great if someone else could have a look too. > > Given the new code in commons-logging that is > intended to address a > similar issue, I think this is worth resolving > before releasing > commons-logging 1.0.5.... > > Regards, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]