DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9255>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9255

Xalan SQL Extension should use context class loader

           Summary: Xalan SQL Extension should use context class loader
           Product: XalanJ2
           Version: 2.3
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xalan.extensions
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


To quote Gary Peskin:

"The SQL Extension uses Class.forName to load the driver in 
DefaultConnectionPool.initializePool(..).  It should probably be using the 
context class loader like we use in the rest of the extension mechanism.

It should be fixed."

Here is the full, original e-mail message, with both replies:

Tobias --

I think Edwin has hit this on the head.  The SQL Extension uses
Class.forName to load the driver in
DefaultConnectionPool.initializePool(..).  It should probably be using
the context class loader like we use in the rest of the extension
mechanism.

I assume that when you manually nuke the entire org.apache pacakge 
from
rt.jar, you've placed the appropriate Xalan jars In your CLASSPATH.  In
this case, as Edwin says, Xalan will be loaded by the application
classloader which will also find your driver.

As Edwin also correctly states, a workaround is to place your driver in
the endorsed dir.

Would you please open a bug in Bugzilla on this?  It should be fixed.

Thanks,
Gary

> -----Original Message-----
> From: Edwin Goei [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, May 20, 2002 11:33 AM
> To: [EMAIL PROTECTED]
> Cc: John Capehart; [EMAIL PROTECTED]; John Sammis
> Subject: Re: SQL Extension Driver Name
> 
> 
> 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