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 15009] New: - Classloading behavior does not follow specification/documentation
Date Mon, 02 Dec 2002 23:48:41 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009

Classloading behavior does not follow specification/documentation

           Summary: Classloading behavior does not follow
                    specification/documentation
           Product: Tomcat 4
           Version: 4.1.12
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: tom.sprenger@adnovum.com


The changes in the class loading behavior introduced in WebappClassLoader from
version 1.34 to 1.35 break with the servlet specification and the current Tomcat
documentation. Primarily, since WebappClassLoader version 1.35 Tomcat tries to
load any class with the system class loader first, ignoring the delegate-Flag
and the possible existence of the class in the web application's context. The
important code fragments in WebappClassLoader.java look like this:

   Version 1.34
   ------------
   // If a system class, use system class loader
   if( name.startsWith("java.") ) {
       ClassLoader loader = system;
       clazz = loader.loadClass(name);
       if (clazz != null) {
           if (resolve)
       ...

   Since version 1.35
   ------------------
   // (0.2) Try loading the class with the system class loader, to prevent
   //       the webapp from overriding J2SE classes
   try {
       clazz = system.loadClass(name);
       if (clazz != null) {
           if (resolve)
               resolveClass(clazz);
       ...

According to the specification it "...is recommended that the application
classloader be implemented in such a way that classes packaged within the WAR
are able to override classes residing in container-wide library JARs.".

In addition, the change made in 1.35 will load any non-system class present in
system classpath _before_ checking the delegation flag, which clearly conflicts
with the current Tomcat documentation.

The changed class loading behavior is especially crucial in connection with the
aspects of isolation and self-containedness of web application. That is, each
web application should be able to provide its own implementations of classes (as
long as these classes don't belong to a system package). Independent of the
target web container's environment it should be guaranteed that the
application's classes are loaded and used prior to any other implementation.

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message