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=37822>. 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=37822 Summary: WebappClassLoader interfering with Catalina core classes Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] This issue has been stumbled upon when I was trying to get Tomcat to cleanly undeploy or hot-restart my web application. What I mean by this is that the WebappClassLoader that loaded the app has to be cleanly garbage collected after hot-redeploy or undeploy. I am running Tomcat 5.5.12 on the latest J2SE 1.6 Mustang build 62. The problem is present on 1.5 as well, it is just Mustang has far better support for JVMTI, so my YourKit profiler is capable of presenting a clear picture of what is going on (see below). DESCRIPTION: My application contains commons-logging.jar (v. 1.0.4) in its WEB-INF/lib directory. The attached pdf file (generated by YourKit profiler, which Tomcat developers are eligible to use as stated on YourKit's website, by the way) shows a GC root of a WebappClassLoader of an undeployed (!) application. This is a residual memory leak. The file also clearly shows that the reason that this classloader is still around is because it is a classloader of org.apache.commons.logging.imp.Log4Jlogger class (which is fine) and that this class instantiated a variable "log" in org.apache.catalina.cor.ApplicationFilterConfig core catalina class (which is disturbing). The above "ensures" that the WebappClassLoader will not be garbage collected. NOTE: The problem can be easily worked around by moving commons-logging.jar and its corresponding log4j.jar into shared/lib directory from the application's WEB-INF/lib. If this is done, then the WebappClassLoader is collected on hot-restarts and undeploys just fine. I believe what I've described indicates a serious bug in classloading delegation inside Tomcat. The bug that prevents any kind of clean hot-deploy or undeploy of all web applications containing commons-logging.jar in their local WEB-INF/lib classpath. Please address this issue as just about any modern application will require commons-logging.jar, simply because it is a required dependency of almost all open source frameworks. -- 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]
