You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by bu...@apache.org on 2004/11/07 20:48:02 UTC

DO NOT REPLY [Bug 31286] - Memory leaks in JBoss due to LogFactory cache

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-11-07 19:48 -------
Had another look at this today and again it looks like the downsides of altering the code outweight the 
upside.

I've been moving towards ideas about using bytecode manipulation to dope commons logging jars. The 
idea would be that though one-size-fits implementations are really not possible, it should be possible 
to use make small changes by altering the bytecode so that (for example) uses of the hashtable are 
replaced by calls to a WeakHashMap. The doped jar would no longer work correctly with certain 
subclasses or pre-Java2 JVMs but would release classloaders.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org