tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregor Schneider" <>
Subject Re: JDBC connection issue
Date Fri, 17 Aug 2007 08:13:41 GMT

then the docs are quite misleading.

In the 5.5-docs
( is

n a J2SE 2 (that is, J2SE 1.2 or later) environment, class loaders are
arranged in a parent-child tree. Normally, when a class loader is
asked to load a particular class or resource, it delegates the request
to a parent class loader first, and then looks in its own repositories
only if the parent class loader(s) cannot find the requested class or
resource. The model for web application class loaders differs slightly
from this, as discussed below, but the main principles are the same.

Then, when you scroll down to almost the end of the page, it is said:

As mentioned above, the web application class loader diverges from the
default Java 2 delegation model (in accordance with the
recommendations in the Servlet Specification, version 2.3, section
9.7.2 Web Application Classloader). When a request to load a class
from the web application's WebappX class loader is processed, this
class loader will look in the local repositories first, instead of
delegating before looking. There are exceptions. Classes which are
part of the JRE base classes cannot be overriden. For some classes
(such as the XML parser components in J2SE 1.4+), the J2SE 1.4
endorsed feature can be used (see the common classloader definition
above). Last, any JAR containing servlet API classes will be ignored
by the classloader. All other class loaders in Tomcat 5 follow the
usual delegation pattern.

Well, I wouldn't call this behaviour "slighty different" from the
default Java-behaviour - it least I just now got caught in that trap.


what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message