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>
|