You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Guy L. Oliver" <ol...@BATTELLE.ORG> on 2002/02/27 20:59:54 UTC
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?
Thanks
Guy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by Remy Maucherat <re...@apache.org>.
> 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?
I may sound like a broken record here, but you should really look at the
latest code, because somehow things may have changed. Thanks for reminding
me that I'll need to update the docs, BTW.
You still need the some exclusion for JAXP, JNDI (to be safe) and the
servlet API, however.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by Remy Maucherat <re...@apache.org>.
> Shouldn't the servlet.jar file be placed on the system classpath by the
> startup scripts? The servlet container itself supports a specific version
> of the servlet API and the web applications should not be able to pick and
> choose which version they wish to use. Placing these classes on the
system
> classpath (along with changing the class/resource loading algorithm) would
> fix this, because webapps would check the system classloader first.
There are some tricks which can be used to put some JARs in the system
classpath (for example, Xerces), but it's not a robust solution and would
break if the user decides it wants to use JAXP 1.2 instead (or just renames
the JARs). So I don't think we should use that kind of solution.
With servlet.jar, it's even harder to do, because of Jasper, which uses
filesystem based compilation, and which would cause compilation errors if
the webapps repositories contained some older version of the servlet API
(the trigger for the Servlet class in the WebappClassLoader avoids this, but
at a price). Note: This was the most often reported user error.
The upcoming 4.0.3 b1 (coming tomorrow or friday; or you can try one of the
nightly builds) will provide a nice compromise, with non intrusive class
filtering, while allowing you to put almost anything you want in the webapp
repositories.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by James Carman <ja...@carmanconsulting.com>.
Shouldn't the servlet.jar file be placed on the system classpath by the
startup scripts? The servlet container itself supports a specific version
of the servlet API and the web applications should not be able to pick and
choose which version they wish to use. Placing these classes on the system
classpath (along with changing the class/resource loading algorithm) would
fix this, because webapps would check the system classloader first.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, February 27, 2002 6:01 PM
Subject: Re: Class Loader Triggers
>
>
> On Wed, 27 Feb 2002, James Carman wrote:
>
> > Date: Wed, 27 Feb 2002 17:09:33 -0500
> > From: James Carman <ja...@carmanconsulting.com>
> > Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> > To: Tomcat Developers List <to...@jakarta.apache.org>
> > Subject: Re: Class Loader Triggers
> >
> > 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?
>
> That would deal with JDK classes, but not others (such as javax.servlet)
> that also have to be protected.
>
> > 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?
> >
>
> You might want to review Section 9.7.2 of the Servlet 2.3 specification.
> It specifically allows the webapp class loader to load first from itself,
> to deal with situations like this:
> * Your webapp needs version X of a particular class library
> (say, a JDBC driver or an XML parser).
> * To ensure that those classes are available, you put the
> corresponding JAR file into /WEB-INF/lib of your webapp.
> * But the person managing your servlet container has
> put version Y of the library in a shared repository (or
> as a system extension).
> * The version X classes in your webapp would be ignored.
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 27 Feb 2002, James Carman wrote:
> Date: Wed, 27 Feb 2002 17:09:33 -0500
> From: James Carman <ja...@carmanconsulting.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: Class Loader Triggers
>
> 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?
That would deal with JDK classes, but not others (such as javax.servlet)
that also have to be protected.
> 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?
>
You might want to review Section 9.7.2 of the Servlet 2.3 specification.
It specifically allows the webapp class loader to load first from itself,
to deal with situations like this:
* Your webapp needs version X of a particular class library
(say, a JDBC driver or an XML parser).
* To ensure that those classes are available, you put the
corresponding JAR file into /WEB-INF/lib of your webapp.
* But the person managing your servlet container has
put version Y of the library in a shared repository (or
as a system extension).
* The version X classes in your webapp would be ignored.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by James Carman <ja...@carmanconsulting.com>.
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" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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
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.
>
> 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
model,
> so triggers are needed (for JAXP, JNDI, and the servlet API classes).
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by Remy Maucherat <re...@apache.org>.
> 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.
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 model,
so triggers are needed (for JAXP, JNDI, and the servlet API classes).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by James Carman <ja...@carmanconsulting.com>.
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" <re...@apache.org>
To: "Tomcat Developers List" <to...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Class Loader Triggers
Posted by Remy Maucherat <re...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>