Stefano Mazzocchi wrote:
> . . . > The problem is simple: when a class contained in a WAR file wants to > load a class, a classloader is invoqued. The Java Language Specification > indicates that the 'normal' flow of classloading fallback is the > following: > > system -> custom classloader -> custom classloader > > so, first of all, the class is loaded from the system and, if not found, > it is asked to the application-defined classloader and so on. A better way to describe this behavior (IMHO anyway :-) is the parent-child heirarchy. Basically, the Java specification says that when a ClassLoader is called upon to load a class, it asks it's parent classloader for the resource before looking for the resource itself. > > . . . > > This problem was identified and solved in Tomcat 4.x by changing the > fallback direction of classloading. So, Tomcat 4.x does > > [war classloader -> tomcat classloader -> system classloader] Actually, it goes: WebApp (WAR) classloader -> Bootstrap/JVM classloader -> "System" classloader -> Tomcat classloader (See http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html for a better description) I agree, the way Tomcat does it is good, and I think your proposal is a good idea. I would speculate that a lot of classloader issues (with other servlet containers) are created by users editing the CLASSPATH variable, to point to their jar files which they have placed wherever they want, or worse, placed in the JDK's directories, which creates problems because then the system classloader trys to load them. The spec already states that necessary JARs and classes should be placed in the webapp/lib and webapp/classes directories. Tomcat realizes this problem as well, and ignores the CLASSPATH environment variable, which I think is good too. David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
