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 [EMAIL PROTECTED] 2005-03-15 15:57 ------- (In reply to comment #7) > > If the "thread context classloader" is adhering to the "parent first" search > behavior, then this would only be a problem if the "thread context > classloader" did not have the "current class's classloader" in it's hierarchy. > I would like to reopen the discussion from this point. The behaviour described above can actually lead (and actually did) to a significant memory leak in the following circumstance: I deploy a web application in Tomcat. The application uses log4j to log, and has commons-logging.jar and log4j.jar in WEB-INF/lib. Tomcat also uses common-loggings. The problem is that I find myslef in the situation where tomcat classes get to use a Log instance loaded by the class loader of my web application (which is, of course, the context class loader during the execution of servlets). This will prevent the web app from being garbage collected when I stop it. The only workaroung for this was to put common-logging.jar and log4j.jar in share/lib instead of WEB-INF/lib, but I'm not really happy with this solution. Could somebody confirm this problem? The guys from Tomcat do not admit this is a bug for them, but I belive this actually affects Tomcat. -- 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]
