Class Loading Question

["Mark R. Diggory" <md...@latte.harvard.edu>]

I'm looking in the ClassLoading documentation and I see this as the 
loading order

/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application
Bootstrap classes of your JVM
System class loader classses (described above)
$CATALINA_HOME/common/classes
$CATALINA_HOME/common/endorsed/*.jar
$CATALINA_HOME/common/lib/*.jar
$CATALINA_HOME/shared/classes
$CATALINA_HOME/shared/lib/*.jar

but when I look at the chart it looks like this:

       Bootstrap
           |
        System
           |
        Common
       /      \
  Catalina   Shared
              /   \
         Webapp1  Webapp2


seems as though the the ordering of the CLASSPATH for my webapp should 
look like this when I consider the chart:

/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application
$CATALINA_HOME/shared/classes
$CATALINA_HOME/shared/lib/*.jar
$CATALINA_HOME/common/classes
$CATALINA_HOME/common/endorsed/*.jar
$CATALINA_HOME/common/lib/*.jar
System class loader classses (described above)
Bootstrap classes of your JVM

Then each level can have "precidence" over the last level, this would be 
benificial in situations where the first package of a particualr type is 
used as a default (ie XML parsers).

Why are the System/bootstrap/common classes listed before shared? Seems 
when one uses the "default" configuration strategy for XML parsers one 
would get stuck with jdk's default crimson instead of tomcat's default 
xerces when working with a "out-of-the-box" installation of Tomcat.

This would allow one to more easily override default settings in the JVM 
Classpath and Tomcat "out-of-the-box" wouldn't have any problems 
associated with using an unfamiliar parser.

-Mark Diggory



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Class Loading Question

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 7 Oct 2002, Mark R. Diggory wrote:

> Date: Mon, 07 Oct 2002 15:07:40 -0400
> From: Mark R. Diggory <md...@latte.harvard.edu>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Class Loading Question
>
> I'm looking in the ClassLoading documentation and I see this as the
> loading order
>
> /WEB-INF/classes of your web application
> /WEB-INF/lib/*.jar of your web application
> Bootstrap classes of your JVM
> System class loader classses (described above)
> $CATALINA_HOME/common/classes
> $CATALINA_HOME/common/endorsed/*.jar
> $CATALINA_HOME/common/lib/*.jar
> $CATALINA_HOME/shared/classes
> $CATALINA_HOME/shared/lib/*.jar
>
> but when I look at the chart it looks like this:
>
>        Bootstrap
>            |
>         System
>            |
>         Common
>        /      \
>   Catalina   Shared
>               /   \
>          Webapp1  Webapp2
>
>
> seems as though the the ordering of the CLASSPATH for my webapp should
> look like this when I consider the chart:
>
> /WEB-INF/classes of your web application
> /WEB-INF/lib/*.jar of your web application
> $CATALINA_HOME/shared/classes
> $CATALINA_HOME/shared/lib/*.jar
> $CATALINA_HOME/common/classes
> $CATALINA_HOME/common/endorsed/*.jar
> $CATALINA_HOME/common/lib/*.jar
> System class loader classses (described above)
> Bootstrap classes of your JVM
>
> Then each level can have "precidence" over the last level, this would be
> benificial in situations where the first package of a particualr type is
> used as a default (ie XML parsers).
>
> Why are the System/bootstrap/common classes listed before shared? Seems
> when one uses the "default" configuration strategy for XML parsers one
> would get stuck with jdk's default crimson instead of tomcat's default
> xerces when working with a "out-of-the-box" installation of Tomcat.
>
> This would allow one to more easily override default settings in the JVM
> Classpath and Tomcat "out-of-the-box" wouldn't have any problems
> associated with using an unfamiliar parser.
>

The standard class loader functionality in Java is "delegate to the parent
before looking locally".  Among other things, this is a security issue --
it guarantees that you can't do wierd things like override the standard
implementation of java.lang.SecurityManager with one of your own.

The servlet spec gives webapp class loaders the option to modify this
class loading order for the webapp class loader, and Tomcat 4 (by default)
does this.  Doing so requires a large number of extra checks to ensure
that a webapp doesn't try to override JDK or servlet API classes.
However, all the other class loaders follow the standard pattern.

> -Mark Diggory

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>