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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
