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 33931] - [beanutils] WeakHashMap incorrectly used in ContextClassLoaderLocal - may cause memory leak
Date Wed, 09 Mar 2005 21:35:57 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=33931>.
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=33931





------- Additional Comments From skitching@apache.org  2005-03-09 22:35 -------
Thanks for pointing this out.

I believe this problem is only struck when:
(a) a parent classloader loads the BeanUtilsBean class.
(b) a child classloader loads a custom BeanUtilsBean subclass, then calls
    BeanUtilsBean.setInstance(customBeanUtilsBean).

I can't imagine why anyone would want to write a custom BeanUtilsBean...can you
suggest why someone would do this?

Assuming there *is* a reason for custom BeanUtilsBean objects to be registered,
I can think of only one solution: 
 * providing a "release" method which clears an entry from the 
   valueByClassLoader map, and documenting that anyone who calls
   setInstance with a BeanUtilsBean subclass must call this on
   webapp unload.

This is an ugly solution, but I don't believe there is any alternative.

It did occur to me that a *clean* solution would be for ClassLoader instances to
provide a generic ThreadLocal-like facility. Rather than have this global
hashmap keyed by ClassLoader, code wanting to store per-classloader info could
just attach the data to the ClassLoader instance. This would solve similar
classloader problems in commons-logging too. Anyone think this is worth
suggesting to the JCP? (though that won't solve the current problem in the
forseeable future :-)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
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