DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31286>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31286 Memory leaks in JBoss due to LogFactory cache ------- Additional Comments From [EMAIL PROTECTED] 2004-09-19 11:35 ------- Yep. I've been aware of this one for quite a while. It's necessary to call release when commons-logging is in the parent classloader of a container. There are a couple of issue which have prevented it being fixed. The first is that commons-logging needs to support JVMs which do not have weak-hash maps. The second is that for some reason the cache implementation (hashtable) was made protected rather than private so a direct change could mean breaking backward compatibility. I can see a few ways round these issues but they aren't not so simple and (to be honest) commons- logging really isn't an itch for me at the moment. The caching needs to be factored out and then some mechanism added to allow how these methods work to vary. A system property might do the trick but I wonder whether it might be possible to use aspect orientation. (I've been wondering whether releasing a vanilla implementation and enhancement scripts might be the long term solution to a host of thorny problems with logging.) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
