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 28291] - [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4
Date Thu, 17 Mar 2005 17:51:39 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=28291>.
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=28291





------- Additional Comments From rdonkin@apache.org  2005-03-17 18:51 -------
When running on Tomcat, the container should call release on the instance loaded
in the shared library after each classloader is deployed. This is why I made
this suggestion.

It's hard to know whether the classloader will get collected upon hot deployment
even when LogFactory is defined by the child classloader on all platforms (which
is why I caveated my answers). Garbage collection and reflection has had some
wrinkles (and bugs). I wouldn't be surprised if it didn't on some (but would
bet on it).

The way that I would have proceeded would have been to set a hot deployment test
for my particular application to determine whether there is a detectable memory
leak. (I believe that this is how the tomcat problems were first recognized.)
However, Chris asked for a therotical answer so I did my best. 


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