Replying to myself:
--- Brian Stansberry <[EMAIL PROTECTED]>
wrote:
> 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
fail.
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.
Brian
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
