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
|