commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31286] - Memory leaks in JBoss due to LogFactory cache
Date Sun, 19 Sep 2004 11:35:25 GMT
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 rdonkin@apache.org  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message