On Wed, 2006-02-22 at 17:45 +1300, Simon Kitching wrote: > On Tue, 2006-02-21 at 22:15 +0000, robert burrell donkin wrote: > > too much caffine for me yesterday (very bad for me resulting in mental > > overdrive and then no sleep). even though i'm tired now, it the manic > > phase may have produced a positive side effect - or possibly just > > another mad idea... > > > > a lot of difficulties (including issues with hot deployment) arise from > > JCL caching classloaders. most of these issues should be addressed by > > using a weakhashtable but there are certain cases where even a weak hash > > table cannot solve the issue. > > > > the reason for indexing on classloaders is to allow configurations to be > > saved on a per classloader basis. it strikes me that identity should be > > as good as equality for this indexing. if so, then we could use > > System.identityHashCode as the index rather than the actual classloader. > > > > please feel free to spot the flaws with this plan :) > > The problem is a shared LogFactory class has a map holding (TCCL, > LogFactoryImpl) pairs. This of course prevents the TCCL from being > collected without an explicit release() call to clear that map entry. > > Using a weakref to the TCCL ensures that the map entry is automatically > deleted when the container drops its reference to the TCCL. > > Using a stringified TCCL would no longer block the TCCL from being > collected. However it would leave the entry in the map forever, ie would > not allow the LogFactoryImpl instance (and all the Log objects held by > it) to be collected. > > And it doesn't fix the corner case "leak" problems that exist with the > current solution either; these occur because the *value* in the map has > an indirect reference to the TCCL. That's only fixable by an explicit > release as far as I know (hence ServletContextCleaner).
yes, that it :) good: for a while i thought that we'd managed to miss a solution. it does lead onto something i've been pondering for a while (though): perhaps it might be possible to discover only the appropriate configuration and then load the classes from the current loader. if this were possible then this would remove the indirect reference provided. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
