commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: logging: WeakHashtable
Date Tue, 16 Nov 2004 22:15:44 GMT
On 16 Nov 2004, at 06:12, Brian Stansberry wrote:

(in general agreement)


> So, it seems like a hard reference in the map to a
> LogFactory is mostly a problem for webapps that
> include commons-logging in WEB-INF when it is already
> available on the server classpath.  Bad practice in
> general to do this, but people do the darnedest
> things.  I know Tomcat and the embedded Tomcat in
> JBoss both guard against this problem by calling
> LogFactory.release() when they undeploy webapps.
> Don't know about other webservers.

i suspect that this will be the case whenever commons-logging is either 
deployed in WEB-INF or only within an ear (not at the system level). i 
believe that in the case of a jar deployed in an ear only, the context 
classloader will be the one used to load the class (since the parent 
won't have a copy available).

in this case, the value would have to (sooner or later) be held by a 
weak reference. it would probably be possible to help in this case by 
counting, holding strong references then clearing them once the get 
count becomes too high. (the typical use case this would address would 
be multiple hot deployments which should result in enough gets.)

having said that, this particular problem now looks more like a 
minority issue...

> (BTW, the problem with JBoss that led to Bug 31286 is
> related to EJB deployments.  commons-logging is on the
> JBoss server classpath (specifically in the
> UnifiedClassLoaderRepository) due to its use in
> embedded Tomcat, so the classloader situation should
> be analogous to #2 above.  JBoss doesn't call
> LogFactory.release() when undeploying EJBs, because if
> embedded Tomcat is not deployed they can't be sure
> LogFactory will be available).

i agree that this case can be clearly addressed by holding a hard 
reference to the factory.

maybe the best approach would be to address what seems to be the 
biggest use case and hold the LogFactory reference with a hard 
reference. i'd to happy to see WeakHashTable changed to use this 

the code to address the other use case is probably do-able but it's 
going to be a bit ugly. could create a similar class (with counts) and 
a similar (though subsidiary) mechanism which tries to load this other 
class in the case when WeakHashTable isn't present. however, bytecode 
manipulation might be more attractive in this case...

- robert

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

View raw message