tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Lutris_Kelp: [Fwd: What Do We Do With The User's Classpath?]
Date Tue, 18 Jul 2000 20:13:36 GMT
Wes Saeger wrote:

> Hi Craig!
> >From your description, I get the following picture (I hope it is
> accurrate!):
>                   Primordial Class Loader
>                                     ^
>                                      |
>                   Extensions Class Loader
>                                     ^
>                                      |
>              --->   System Class Loader
>             |                        ^
>             |                         |
>             |        Bootstrap Class Loader
>             |                                      ^
>             |                                       |
>        Appl Class Loader       Catalina Class Loader

(Almost) right the first time -- I think.  From my reading of the Java2
classloader stuff, it seems like it really ends up like this:

        |               |
    Extensions       Internal
        |             Classes
    System (what
    JDK calls the
        Web App Class

> The system class loader (which loads the class containing "main") is created
> by the VM and uses CLASSPATH to load classes.  In your case, CLASSPATH is
> overwritten to point to only $CATALINA_HOME/lib.  This is where classes
> common to all web apps are placed.

Actually, the "main()" method is loaded by the bootstrap loader.  This is
because I didn't want to make the rest of the Catalina classes visible to
application classes -- and they would be (for class loaders that follow the
"delegate to the parent" rule).

> The bootstrap class loader.  I'm a little confused here.  Maybe this doesn't
> exist and the Catalina class loader's parent is the System class loader?  I
> think this detail is minor...

The bootstrap class loader is a Java2 innovation, and lets you plug in classes
at the "top" of this hierarchy instead of the botttom -- in essence, you can
override JDK native classes as well as installed extensions (jre/lib/ext
directory).  However, anything you put here is visible down the chain.

You specify the classpath for the bootstrap class loader with -Xbootclasspath on
the command line -- it defaults to the "rt.jar" and "i18n.jar" files in

> The Catalina class loader loads Catalina implementation classes from
> $CATALINA_HOME/server.  These classes are completely hidden from the Web
> apps.


> The application class loader loads application specific classes from
> WEB-INF/classes and WEB-INF/lib.  These classes are hidden from the Catalina
> class loader.

App classes can come from the "web app" loader that looks at WEB-INF/classes and
WEB-INF/lib, but then goes to the system class loader for classes that are not
found.  In that way, the sysadmin can install shared JAR files for commonly used
libraries, without making every app install their own copy.

The web app class loader gets created with the no-args constructor, which causes
the "system" class loader to be its parent.  That is why the internal classes
aren't visbile, even though this class loader is in fact created by a class in
the internal class path.

> If the above picture is somewhat accurrate and the delegation model is
> followed, then this scheme is similar to what I proposed.   The main
> difference is that you place common classes in the system class loader and I
> use a separate class loader for this.
> I will see if I can get the code and have a closer look.

Good.  I will be interested in your comments.

> Wes

Craig McClanahan

View raw message