commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: [beanutils] [logging]j2ee unit tests added: memory leak demonstrated (?)
Date Wed, 16 Mar 2005 08:21:54 GMT
Replying to myself:
--- Brian Stansberry <>
> 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.

After exploring more with the JCL code, I'm almost
certain the reference to FloatConverter in
BeanUtilsBean.convertUtilsBean.converters is what's
causing o.a.c.beanutils.converter.MemoryTestCase to

When I wrote before, I only said "likely" because I
couldn't see why JCL wouldn't always have the same
failure, and I had tests where it didn't.  But I've
now created tests where it does (see below); tests
that are basically analogous to MemoryTestCase.

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

Will have to be another day before I submit a patch
for the JCL tests (after midnight now).  But, I've
found in JCL the classloader is not released when
LogFactoryImpl is loaded by a parent loader and the
Log wrapper is loaded  by a child.  I've identified
two basic configurations where this might happen:

1) Parent-first delegation model, where the parent has
commons-logging-api.jar, child has commons-logging.jar
and child wants to use Log4j or Avalon (or some custom
Log implementation).

2) Child-first delegation model that uses the
configuration I proposed in my "Further Analysis"
document; i.e. where the parent has
commons-logging-api-xxx.jar, child has
commons-logging-impl.jar and child wants to use Log4j
or Avalon.


Do you Yahoo!? 
Make Yahoo! your home page

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

View raw message