tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: Class Loader Triggers
Date Wed, 27 Feb 2002 20:48:00 GMT
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 system
class loader (which loads the core libraries and all standard extensions) 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 whole
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 classes12.zip (in the case of the Oracle
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.



----- Original Message -----
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Wednesday, February 27, 2002 3:36 PM
Subject: Re: Class Loader Triggers


> > I've been going through the code that deals with loading classes at
> > different levels, and have run into something that doesn't make any
> > sense to me.  Perhaps someone here can direct me in the right place.
> > I'm working with this under jdk1.4.
> >
> > Specifically, in startup.ClassLoaderFactory, there is a list of
> > trigger classes that will cause a jar file to be ignored.  In this
> > case, it has javax.sql.DataSource in it.  I don't exactly understand
> > the reasoning behind deciding what should be included in here and what
> > shouldn't, but for the time being, I am willing to accept that there
> > is a good reason for there being no javax.sql.DataSource containing
> > jar files.
> >
> >     private static String[] triggers = {
> >         "com.sun.jndi.ldap.LdapCtxFactory",      // LDAP      added in
> > 1.3
> >         "com.sun.net.ssl.internal.ssl.Provider", // JSSE      added in
> > 1.4
> >         "javax.naming.Context",                  // JNDI      added in
> > 1.3
> >         "javax.net.SocketFactory",               // JSSE      added in
> > 1.4
> >         "javax.security.cert.X509Certificate",   // JSSE      added in
> > 1.4
> >         "javax.sql.DataSource",                  // JDBC ext. added in
> > 1.4
> >         // "javax.xml.parsers.DocumentBuilder",     // JAXP      added
> > in 1.4
> >         "org.apache.catalina.startup.Bootstrap", // Don't load
> > ourselves
> >         // "org.apache.crimson.jaxp.DocumentBuilderImpl",
> >                                                  // Crimson   added in
> > 1.4
> >     };
> >
> >
> >
> > In loader.WebappClassLoader, there is a second list of trigger classes
> > that will prevent a jar file from being loaded up.
> >
> >     private static final String[] triggers = {
> >         "com.sun.jndi.ldap.LdapCtxFactory",      // LDAP      added in
> > 1.3
> >         "com.sun.net.ssl.internal.ssl.Provider", // JSSE      added in
> > 1.4
> >         "javax.security.auth.Subject",           // JAAS      added in
> > 1.4
> >         //"javax.net.SocketFactory",               // JSSE      added
> > in 1.4
> >         //"javax.security.cert.X509Certificate",   // JSSE      added
> > in 1.4
> >         //"javax.sql.DataSource",                  // JDBC ext. added
> > in 1.4
> >         //"javax.xml.parsers.DocumentBuilder",     // JAXP      added
> > in 1.4
> >         "javax.servlet.Servlet",                 // Servlet API
> >         // "org.apache.crimson.jaxp.DocumentBuilderImpl",
> >                                                  // Crimson   added in
> > 1.4
> >     };
> >
> > In this case, there is a different list of files that are excluded.
> >
> > So, for some reason, it has been decided that something like
> > javax.sql.DataSource is legal as a class file in a webapp library, but
> > not in a system wide library, such as is found in CATALINA/common/lib
> >
> > My question is, if having javax.sql.DataSource was a problem in the
> > parent class loader, why isnt it a problem in the lower loaders?
> >
> > AS a bit of history, I started looking into this when I found that I
> > could not place oracles jdbc driver jar in common/lib and have it be
> > recognized, but it would in the webapps lib dir.  I tracked it down to
> > this trigger list kicking it out of the parent class loader.
> >
> > The problem with it doing this for me was that I am using jdbc realms
> > (and was thinking about playing around with jdbc session persistence)
> > and was going to point both of these to oracle.  Oracle's jdbc jar has
> > javax.sql.DataSource in it, and it conflicts with the trigger present
> > in the code.
> >
> > I'm fairly sure I could fix this by simply removing
> > javax.sql.DataSource from the oracle jar file.   But, id feel better
> > about it if I knew exactly why it is not allowed in the higher level
> > class loaders in the first place.
> >
> > Also, does any one else feel that the jdbc driver from oracle should
> > not be including that class at this time, now that 1.4 has DataSource
> > in it by default?
>
> This code has been modified since then. You should use CVS to get the
> latest.
>
> Thanks,
> Remy
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-dev-help@jakarta.apache.org>
>
>
>
>




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message