cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [help needed] Patching the Servlet API on classloading
Date Mon, 17 Jun 2002 10:09:19 GMT

I've asked Jason Hunter (one of our representatives in the Servlet API
JSR) if Servlet 2.4 (which is going to be finalized soon) is being more
explicit on the way the classloaders are supposed to load classes from
WAR files.

If Servlet 2.4 was explicit on the 'direction' that classloading
fall-back should work, than Cocoon (and any other WARs) will be much
more portable across containers and classloading hells will simply be a
thing of the past (except for those libraries where static calls are
used, see log4j).

He said that nothing has been changed to fix that, but he'll be happy to
run a proposal on my (our?) behalf thru the list. Having been a member
of that JSR for years, you can be sure the proposal will be heard.

So, I'll try to write something down here, if you have any
comments/suggestions, please, let me know ASAP.

                             ---- cut here ----

                       Fixing WAR portability issues

 Author: Stefano Mazzocchi ( [former member of
         [your names will be here]

 State of the art

Interoperability between servlet containers has always been a goal of
the Servlet API. The WAR concept was, in fact, introduced to allow
servlet/jsp-based web applications to be easily deployable on a
container without further hassle.

Unfortunately, the Servlet API failed to describe in explicit terms
*how* the servlet container must treat this WAR file. I'm not talking
about 'how to deploy', since this is obviously an implementation detail,
but about 'how to use a deployed WAR'.

 Current problems

With the advent of server-side XML technology, WAR file portability
suffers from what it is now known as "xml parser hell" or simply "stupid
classloader ignores my jar files!"

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

 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.

Unfortunately, this behavior breaks WAR portability in those containers
that expose the classes that are overwritten by the WAR file.

NOTE: JDK 1.4 fixed this by providing an 'endorsed' directory where you
place your jars that you want to overwrite the classes shipped with the
rt.jar of the JVM, so for JDK 1.4, the classloading flow becomes
 endorsed classloader -> system classloader -> application classloader

Still, implies that 'deploy and forget' of WAR files is not possible
across containers.

 Current Solutions

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]  

this allows several nice things:

 1) 'deploy and forget' works.
 2) you can have different WARs including different versions of the same
library (say a JAXP 1.0 parser and a JAXP 1.1 parser), without


Our proposal is to include a section in the Servlet API 2.4 that makes
the classloading fallback direction explicit and forces servlet
containers to implement this classloading behavior to be said
'compliant' with this version of the API.

We want to enphasize that no changes *whatsoever* are required both to
the Servlet API, nor to the DTDs describing the various deployment
descriptors. Those are just instructions to the servlet container
implementors, but that guarantee a common classloading behavior across
containers that increases interoperability.

Also, we'd like to point out that impact on exising functionality and
implementations is minimal: a JSP engine is very likely to provide
already a nested classloading implementation, so changing the direction
of fallback is a matter of changing the order of call between system
classloader and the custom classloaders.

Also, the impact on previous WAR deployment behavior is minimal: all
WARS that don't contain jars or classes are not affected by this change
and those who do, it doesn't make any difference for them if their
classes are looked up immediately instead of after failing looking them
up in the system classpath and falling back to the web-inf/lib


If the Servlet API 2.4 makes this classloading behavior explicit and
forces all containers to 'behave' the same way, WAR interoperability
will be incredibly augmented, expecially for servlets that need lots of
libraries (and this is become more and more the case with servlet-based
web frameworks)

Thanks for your time and consideration.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message