tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37822] New: - WebappClassLoader interfering with Catalina core classes
Date Wed, 07 Dec 2005 19:30:51 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=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: kyrill@technolog.ca


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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message