commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <>
Subject Re: logging: WeakHashtable
Date Mon, 15 Nov 2004 23:27:54 GMT

--- robert burrell donkin
<> wrote:

> On 12 Nov 2004, at 06:55, Brian Stansberry wrote:
> > But then I thought, wait, should the values be
> held in
> > WeakReferences?  In a typical case where the
> > application just calls LogFactory.getLog(), won't
> the
> > only reference to the LogFactory instance be the
> value
> > in the map?  In this case a lot of calls to
> getLog()
> > will end up going through the getFactory()
> discovery
> > mechanism as the GC keeps clearing the values from
> the
> > hashtable.
> this is actually quite a big issue.
> the reason why i made the LogFactory references
> weakly held was that 
> there's a strong reference from any object to it's
> classloader (via 
> getClass().getClassloader(). (unless there's some
> special mojo for this 
> case which i'm unaware of) i'd say that whilst the
> LogFactory is hard 
> referenced, so is it's classloader.
> (i should probably create a test to prove this
> reasoning.)
Interesting.  The
LogFactoryTest.testReleaseFactories()  test
inadvertently shows a classloader is released. 
However, in the test, LogFactoryImpl was not loaded by
the classloader that creates the map key.  I can play
with this tonight to see what happens if I change

> but you're absolutely right that using a weak
> reference to hold the 
> LogFactory may well result in poor performance. i've
> tried to think my 
> way around this one, by thinking of possible ways of
> reference the two 
> but (so far) i haven't come up with one.
> the only alternative approaches i've come up with so
> way are more than 
> a little ugly, using counters (timers or something)
> so that references 
> to values are weakened periodically.
> anyone have any better ideas?
I'm at work at the moment, so can't think too much ;-)

Would getClass().getClassloader() return the Thread
contextClassLoader that was in effect when
getFactory() was first called, or a parent classloader
if the parent was the one that actually loaded the
class?  E.g. a situation where a web app classloader
first calls getFactory(), but because
commons-logging.jar is on the server classpath it is
actually loaded by a server classloader. I can test
this tonight as well.

- brian

Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 

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

View raw message