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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
