Scott Ferguson wrote (2009-03-30 18:20):
> On Mar 30, 2009, at 3:54 AM, Mattias Jiderhamn wrote:
>> After drawing the conclusion below, it isn't very far away to realize
>> it probably has to do with some static (i.e. class loader specific)
>> member of EnvironmentClassLoader.
>> And just as I thought, the heart of the problem is
>> private static EnvironmentLocal<ArrayList<AddLoaderListener>>
>> More specifically, if line 234 of com.caucho.server.resin.Resin is
>> commented out, the leak is removed (assuming my
>> HttpRequest._invocation patch is also applied)
>> // Environment.addChildLoaderListener(new WebBeansAddLoaderListener())
>> Scott, you said the WebBeans caches were not to blame because they
>> are classloader local. Well, it seems something about this
>> classloader locality isn't working the way it should, doesn't it...?
>> Do you have enough info to try to fix this in a future (hopefully
>> soon to be released) 3.1 release?
> In the early work with 4.0, I'd cleaned a number of dead links
> (primarily WebBeans, but also some JMX). I believe the current 4.0
> still has a few left, so I'll need to run a final pass at the end of
> the release cycle.
Are you saying this won't be fixed in the 3.1 branch? I'm assuming the
4.0 production release is still months ahead?
Could we provide you any additional information to change your mind...?
resin-interest mailing list