tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: Class Loader Triggers
Date Wed, 27 Feb 2002 20:36:59 GMT
> 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>


Mime
View raw message