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:[EMAIL PROTECTED]] > > Sent: Monday, May 20, 2002 12:17 PM > > To: [EMAIL PROTECTED] > > Cc: 'John Capehart'; [EMAIL PROTECTED]; '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:[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 > > > > > > > > > > -- > > Tobias McNulty > > Data Description, Inc. > > 840 Hanshaw Road, Suite 9 > > Ithaca, NY 14850 > > Phone: (607) 257-1000 > > E-mail: [EMAIL PROTECTED] > > Web: www.datadesk.com > > -- -------------------------------------- John Gentilin Eye Catching Solutions Inc. 18314 Carlwyn Drive Castro Valley CA 94546 Contact Info [EMAIL PROTECTED] Ca Office 1-510-881-4821 NJ Office 1-732-422-4917
