tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Lutris_Kelp: [Fwd: What Do We Do With The User's Classpath?]
Date Wed, 19 Jul 2000 15:00:25 GMT
Wes Saeger wrote:

> [snip]
>
> [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.
>

Yes ... that is my understanding as well.

>
> >
> > 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
> 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.
>
> 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...)
>

That is also my understanding.  It tried to minimize the number of
classes I
actually needed in the bootstrap.jar, because these classes are in fact
visible
to web apps that go to the effort of calling getSystemClassLoader().

> [snip]
> 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...
>

I agree that it is backwards from the current Java2 delegation model. 
However,
consider the following use case:

* System manager has installed version X of the FooBar JDBC driver
  as a shared library (on the system class path).

* A particular application installed in this container installation
requires
  some patches that were applied in version Y of the FooBar JDBC
  driver, so the developer included this jar in WEB-INF/lib.

* If the traditional delegation model, is followed, none of the version
Y
  classes are used (they have the same class names, after all), so the
  container vendor gets a bug report "your *&*&(*$&*#(& container
  won't load my classes even though they are in the WEB-INF/lib
directory!!!"
  Trying to blame the sysadmin for installing version X as a shared
library
  isn't going to get us very far, because she's got existing
applications
  that require it, and she sees no need to duplicate it on all the
existing
  web-apps just for this new app to work.

* If the existing Catalina model is followed, this one app uses the
version Y
  classes and everyone else continues to rely on the existing shared
  version X driver installed in the container.  Peaceful coexistence
reigns,
  and everyone lives happily ever after.  :-)

Ultimately, class loading order is an issue that needs to be addressed
in the
2.3 servlet spec, so that all containers implement it the same way.

Craig

Mime
View raw message