tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guy L. Oliver" <oliv...@BATTELLE.ORG>
Subject Class Loader Triggers
Date Wed, 27 Feb 2002 19:59:54 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
        "", // JSSE      added in
        "javax.naming.Context",                  // JNDI      added in
        "",               // JSSE      added in
        "",   // JSSE      added in
        "javax.sql.DataSource",                  // JDBC ext. added in
        // "javax.xml.parsers.DocumentBuilder",     // JAXP      added
in 1.4
        "org.apache.catalina.startup.Bootstrap", // Don't load
        // "org.apache.crimson.jaxp.DocumentBuilderImpl",
                                                 // Crimson   added in

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
        "", // JSSE      added in
        "",           // JAAS      added in
        //"",               // JSSE      added
in 1.4
        //"",   // 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

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?


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

View raw message