You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Tobias McNulty <tm...@datadesk.com> on 2002/05/20 18:54:21 UTC

Re: SQL Extension Driver Name

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?

Thanks,
Toby

At 12:04 PM -0500 4/3/02, Tobias McNulty wrote:
>After I finally got the SQL Extension working last week, I've 
>managed to break it again.  At least now I get some errors:
>
>Is the "Invalid Driver Name Specified!" error in reference to the 
>package & class name of the driver?  The driver is in my classpath, 
>and I tested it by instantiating a copy of the driver in the Java 
>code, but the XSL still can't find it!
>
>Is there something else I might be missing here?
>
>Thanks much,
>Toby
>--
>Tobias McNulty
>Data Description, Inc.
>840 Hanshaw Road, Suite 9
>Ithaca, NY 14850
>Phone: (607) 257-1000
>E-mail: tmcnulty@datadesk.com
>Web: www.datadesk.com


-- 
Tobias McNulty
Data Description, Inc.
840 Hanshaw Road, Suite 9
Ithaca, NY 14850
Phone: (607) 257-1000
E-mail: tmcnulty@datadesk.com
Web: www.datadesk.com

Re: SQL Extension Driver Name

Posted by John Gentilin <ge...@eyecatching.com>.
I will make the fix, I am currently getting back into the Xalan SQL code
for a new project. It should be in there in the next day or so. Also for a
quick fix, you could write you own wrapper for the ConnectionPool code
and register it with the ConnectionPoolMgr. If you are doing any type
of repetive stuff this is the way to go. In your wrapper, you can load the
driver any way you want.


-JG


Gary L Peskin wrote:

> I would submit the bug over at Xerces.
>
> Gary
>
> > -----Original Message-----
> > From: Tobias McNulty [mailto:tmcnulty@datadesk.com]
> > Sent: Monday, May 20, 2002 12:17 PM
> > To: xalan-dev@xml.apache.org
> > Cc: 'John Capehart'; mprentice@datadesk.com; 'John Sammis'
> > Subject: RE: SQL Extension Driver Name
> >
> >
> > Submitted -- though I just quoted you :)
> >
> > The document-class-name property in Xerces appears to suffer from the
> > same problem.  Are the appropriate people reading this or should I
> > submit another bug report for xerces?
> >
> > Toby
> >
> > At 11:50 AM -0700 5/20/02, Gary L Peskin wrote:
> > >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:edwingo@sun.com]
> > >  > Sent: Monday, May 20, 2002 11:33 AM
> > >>  To: xalan-dev@xml.apache.org
> > >>  Cc: John Capehart; mprentice@datadesk.com; 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
> > >  >
> >
> >
> > --
> > Tobias McNulty
> > Data Description, Inc.
> > 840 Hanshaw Road, Suite 9
> > Ithaca, NY 14850
> > Phone: (607) 257-1000
> > E-mail: tmcnulty@datadesk.com
> > Web: www.datadesk.com
> >

--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546

    Contact Info
gentijo@eyecatching.com
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917




RE: SQL Extension Driver Name

Posted by Gary L Peskin <ga...@firstech.com>.
I would submit the bug over at Xerces.

Gary

> -----Original Message-----
> From: Tobias McNulty [mailto:tmcnulty@datadesk.com] 
> Sent: Monday, May 20, 2002 12:17 PM
> To: xalan-dev@xml.apache.org
> Cc: 'John Capehart'; mprentice@datadesk.com; 'John Sammis'
> Subject: RE: SQL Extension Driver Name
> 
> 
> Submitted -- though I just quoted you :)
> 
> The document-class-name property in Xerces appears to suffer from the 
> same problem.  Are the appropriate people reading this or should I 
> submit another bug report for xerces?
> 
> Toby
> 
> At 11:50 AM -0700 5/20/02, Gary L Peskin wrote:
> >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:edwingo@sun.com]
> >  > Sent: Monday, May 20, 2002 11:33 AM
> >>  To: xalan-dev@xml.apache.org
> >>  Cc: John Capehart; mprentice@datadesk.com; 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
> >  >
> 
> 
> -- 
> Tobias McNulty
> Data Description, Inc.
> 840 Hanshaw Road, Suite 9
> Ithaca, NY 14850
> Phone: (607) 257-1000
> E-mail: tmcnulty@datadesk.com
> Web: www.datadesk.com
> 


RE: SQL Extension Driver Name

Posted by Tobias McNulty <tm...@datadesk.com>.
Submitted -- though I just quoted you :)

The document-class-name property in Xerces appears to suffer from the 
same problem.  Are the appropriate people reading this or should I 
submit another bug report for xerces?

Toby

At 11:50 AM -0700 5/20/02, Gary L Peskin wrote:
>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:edwingo@sun.com]
>  > Sent: Monday, May 20, 2002 11:33 AM
>>  To: xalan-dev@xml.apache.org
>>  Cc: John Capehart; mprentice@datadesk.com; 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
>  >


-- 
Tobias McNulty
Data Description, Inc.
840 Hanshaw Road, Suite 9
Ithaca, NY 14850
Phone: (607) 257-1000
E-mail: tmcnulty@datadesk.com
Web: www.datadesk.com

RE: SQL Extension Driver Name

Posted by Gary L Peskin <ga...@firstech.com>.
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:edwingo@sun.com] 
> Sent: Monday, May 20, 2002 11:33 AM
> To: xalan-dev@xml.apache.org
> Cc: John Capehart; mprentice@datadesk.com; 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
> 


Re: SQL Extension Driver Name

Posted by Edwin Goei <ed...@sun.com>.
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