Tobias McNulty wrote:
> 
> So here's the deal:
> 
> I'm using J2SDK 1.4, in which Sun thoughtfully decided to include all
> of the Xerces/Xalan code in rt.jar.  To account for the _possibility_
> of updates to Xerces/Xalan, Sun introduced the "Endorsed Standards
> Override Mechanism"
> (http://java.sun.com/j2se/1.4/docs/guide/standards/).
> 
> I'm using the SQL Extension with my own JDBC driver in an attempt to
> display data using XSL from a legacy database-like program.  It works
> great when I manually nuke the entire org.apache package from rt.jar
> (so that java can find the xerces/xalan jars I provide).  But, when I
> leave rt.jar untouched, and place the xerces/xalan jars in the
> 'endorsed' folder as Sun indicates we should do, the SQL extension
> cannot find my JDBC driver ("Invalid Driver Name Specified!", SQL
> extension reports).
> 
> Does anyone have experience with the 'endorsed' mechanism, or have any
> other thoughts that might assist in solving this problem?

Someone pointed me to your posting and perhaps this may help:

Placing Xalan.jar in the endorsed dir would be functionally equivalent
to prepending xalan.jar to the bootclasspath which contains rt.jar.  If
you are placing your JDBC driver on the user classpath, then depending
on how the SQL Extension code is written, it may not see the JDBC driver
classes.

In JDK 1.4, if the Xalan SQL Extension uses the current classloader and
is on the bootclasspath, then it will only "see" the classes on the
bootclasspath.  For a workaround, try also installing your JDBC driver
in the endorsed dir as xalan.jar.

One way to fix this may be for the SQL Extension to use the context
classloader as well as the current classloader.

I believe the real fix for these kinds of problems would be to rename
the apache classes that are bundled into the JDK under something like
sun.org.apache.*.  But, b/c of lack of resources and stability concerns,
this may not happen for a while.  This would allow users to place newer
versions of apache classes on the user classpath w/o interference from
the JDK.

-Edwin

Reply via email to