tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject Re: Class Loader Triggers
Date Wed, 27 Feb 2002 22:09:33 GMT
The documentation states (as you've pointed out) that...
Therefore, from the perspective of a web application, class or resource
loading looks in the following repositories, in this order:

  a.. /WEB-INF/classes of your web application
  b.. /WEB-INF/lib/*.jar of your web application
  c.. Bootstrap classes of your JVM
  d.. System class loader classses (described above)
  e.. $CATALINA_HOME/common/classes
  f.. $CATALINA_HOME/common/lib/*.jar
  g.. $CATALINA_HOME/classes
  h.. $CATALINA_HOME/lib/*.jar
Wouldn't it be better to do it this way...

  a.. Bootstrap classes of your JVM
  b.. System class loader classses (described above)
  c.. /WEB-INF/classes of your web application
  d.. /WEB-INF/lib/*.jar of your web application
  e.. $CATALINA_HOME/common/classes
  f.. $CATALINA_HOME/common/lib/*.jar
  g.. $CATALINA_HOME/classes
  h.. $CATALINA_HOME/lib/*.jar
I mean, shouldn't the WebappClassLoader first check with the system
classloader, then try to load the classes itself, then go to its parent (the
"shared" classloader)?  Wouldn't that solve our little problem with these
"trigger" classes?  If this was done, we wouldn't have to worry about
changing the code if Sun decides to include another standard extension in
the core libraries in future versions of the JDK.  What do you guys think?

----- Original Message -----
From: "Remy Maucherat" <>
To: "Tomcat Developers List" <>
Sent: Wednesday, February 27, 2002 3:53 PM
Subject: Re: Class Loader Triggers

> > In my opinion, this is a bad design decision.  ClassLoaders are supposed
> to
> > delegate to their parent before attempting to load a class and the
> > class loader (which loads the core libraries and all standard
> is
> > the parent of all classloaders.  So, if you're worried about
> > javax.sql.DataSource being loaded from a rogue jar file, it won't!
> >
> > It will
> > be loaded by the system class loader since it can find it.  So, this
> > idea of "trigger" classes is unnecessary!  This should be removed, as it
> is
> > causing tremendous problems!  As a workaround, all you have to do is
> remove
> > the javax.sql.* classes from your (in the case of the
> > JDBC drivers) file.  But, this should not be necessary.  Oracle should
> > remove the javax.sql.* files in later releases targeted for the JDK1.4,
> but
> > it shouldn't be a requirement.
> As I said, please check the latest source (the triggers in
> ClassLoaderFactory was old code I forgot to remove :-().
> As for the webapp repositories, they don't use the normal delegation
> so triggers are needed (for JAXP, JNDI, and the servlet API classes).
> Remy
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message