On 16 Nov 2004, at 06:12, Brian Stansberry wrote:
(in general agreement)
<snip>
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 strategy.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
