tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wes Saeger" <>
Subject Re: Lutris_Kelp: [Fwd: What Do We Do With The User's Classpath?]
Date Tue, 18 Jul 2000 22:24:58 GMT

Thanks, your info helped a lot!   See my additional comments below (along
with an updated picture):


----- Original Message -----
From: Craig R. McClanahan <>
To: <>
Sent: Tuesday, July 18, 2000 3:13 PM
Subject: Re: Lutris_Kelp: [Fwd: What Do We Do With The User's Classpath?]

> 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

Here's an updated picture:

                  Primordial Class Loader
                  Extensions Class Loader
                       System 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:
>     Bootstrap-----------\
>         |               |
>     Extensions       Internal
>         |             Classes
>     System (what
>     JDK calls the
>     "Application")
>         |
>         Web App Class
>       Loader
> > The system class loader (which loads the class containing "main") is
> > by the VM and uses CLASSPATH to load classes.  In your case, CLASSPATH
> > 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
> "delegate to the parent" rule).

Okay, I see what's going on here.  The class containing "main" is on the
bootstrap class path (specified using the -Xbootclasspath runtime option)
and is loaded by the primordial (bootstrap) class loader. [Note that classes
loaded by the primordial class loader are considered trusted.]

> >
> > The bootstrap class loader.  I'm a little confused here.  Maybe this
> > exist and the Catalina class loader's parent is the System class loader?
> > think this detail is minor...
> >
> The bootstrap class loader is a Java2 innovation, and lets you plug in
> at the "top" of this hierarchy instead of the botttom -- in essence, you
> override JDK native classes as well as installed extensions (jre/lib/ext
> directory).  However, anything you put here is visible down the chain.

[The discussion below is based on the Java 1.2 class loader scheme.  Things
are slightly different pre 1.2]

Yes, the bootstrap (what I call the primordial) class loader is at the top
of the hierarchy and it loads JDK classes and other classes found
on -Xbootclasspath.  Extension classes (jre/lib/ext) are loaded by the
Extentions class loader which is a child of the primordial class loader.
The system class loader is a child of the Extension class loader.  [Note:
The system class loader is the class loader typically returned by the
ClassLoader.getSystemClassLoader() method.]  The system class loader uses
CLASSPATH.  It is the class loader that USUALLY loads the "main" and other
application classes.  In your case, the system class loader doesn't load
"main".  This is because the system class loader first delegates to its
parent (Entensions CL), which delegates to it's parent (the Primordial CL)
which finds the "main" class and loads it.  All this happens before the
system class loader even tries to load the class itself (it wouldn't find
the class anyway since it is not on CLASSPATH).  In a running environment
using the delegation model, the Primordial, Extension, and System class
loaders always attempt to load a class first (and in that order) before any
other class loaders.

> 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
> $JAVA_HOME/jre/lib.
> >
> > The Catalina class loader loads Catalina implementation classes from
> > $CATALINA_HOME/server.  These classes are completely hidden from the Web
> > apps.
> >
> Correct.
> >
> > The application class loader loads application specific classes from
> > WEB-INF/classes and WEB-INF/lib.  These classes are hidden from the
> > 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
> 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
> the "system" class loader to be its parent.  That is why the internal
> aren't visbile, even though this class loader is in fact created by a
class in
> the internal class path.

Just to make sure we are on the same pager here... There is a small set of
Catalina classes that are loaded by the Primordial class loader by placing
these classes in the -Xbootclasspath.  The rest of the Catalina
implementation classes are loaded by the Catalina class loader which is a
child of the System class loader.  If this is correct then, the classes
loaded by the Catalina class loader are NOT visible to the classes loaded by
the Web Application class loaders (and visa-versa) because these class
loaders are siblings.  BUT, all the Web Apps DO see those few Catalina
classes in the Primordial class loader because the Primordial class loader
is an ancestor of the Web App class loaders.  (I don't think this a problem,
I'm just trying to state the facts...)
> >
> > 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.

I looked at FileClassLoader and only have the following comment:

The general order of searching (in getResource, loadClass,
getResourceAsByteArray) is backwards from the delegation model.  You should
check cache, then check parent, then check yourself, and then raise
ClassNotFoundException.  It is this delegation scheme that guarantees that
classes from less trusted sources don't override classes from more trusted
sources.  This model may also improve performance.  Since most of the
classes that are loaded are java system and extension classes, most class
loading can be resolved before any application level class loader has to
search thru its class path looking for the class.  I realize that your class
loader has the notion of restricted and system classes, but my gut tells me
that mechanisn isn't as clean the delegation scheme.  But then again, maybe
it solves other issues that I'm just not aware of...

> >
> > Wes
> >
> Craig McClanahan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message