cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Haraburda <>
Subject Re: [help needed] Patching the Servlet API on classloading
Date Tue, 18 Jun 2002 19:43:31 GMT
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
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

for a better

I agree, the way Tomcat does it is good, and I think your proposal is a good

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.


To unsubscribe, e-mail:
For additional commands, email:

View raw message