db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Handa <Amit.Ha...@Sun.COM>
Subject Re: How does an application get access to JDBC implementation classes
Date Tue, 22 Nov 2005 06:32:49 GMT


David W. Van Couvering wrote:

> Thanks, Dan.  Can you point me to something that talks more about what 
> it means to be a "valid OSGi bundle?"
>
> Lance, do you have any information on how a driver is loaded in JDBC4 
> using the service provider mechanism?
>
First the driver loading mechanism is applicable for non managed 
scenarios or stand alone java programs.
This will realy not have any value in a managed environment.

Second this is based on packaging your driver jar as a Service based 
upon the Jar Specification
(java.util.Service is part of Mustang)
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider

When a driver is *packaged as a Service*,  you don't need to  explicitly
(1) know the name of the class
(2) load that implementation of java.sql.Driver class explicitly to get 
a connection handle

Further this feature will not break any backward compatibility, all 
applications running will work fine
with new versions of java as long as you
(1) don't package your driver class as a service AND
(2) keep doing Class.forName(x.y.z);

But this is a good Ease of Development feature where the user need not 
be bothered about
knowing the java.sql.Driver implementation class and then loading it.

thanks,
Amit

> Thanks,
>
> David
>
> Daniel John Debrunner wrote:
>
>> David W. Van Couvering wrote:
>>
>>> OK, I think I may have the answer to my question.  Looking at the JDBC
>>> API, here is what I can figure out.  There are the following Connection
>>> factories that a JDBC implementation must provide:
>>>
>>> Driver
>>> DataSource
>>> XADataSource
>>> ConnectionPoolDataSource
>>>
>>> Next question:
>>>
>>> How do the instances of these get created?  
>>
>>
>>
>> In addition to the other ways already discussed, JDBC 4.0 is adding the
>> automatic registration of JDBC drivers using the "Java Standard Edition
>> Service Provider mechanism". Thus in JDBC 4.0, this is valid JDBC code.
>>
>> public static void main(String[] args)
>> {
>>    // no need to load a driver
>>    Connection conn = DriverManager.getConnection("jdbc:derby:cs");
>> }
>>
>> This may have an impact on those looking at class loaders to support
>> multiple Derby drivers. I didn't find (in a very quick look) any
>> information on Java SE Service Provider, and how it handles class 
>> loading.
>>
>> Also derby.jar is a valid OSGi bundle, this may also have some impact on
>> those looking at class loaders for multiple multi-version derby 
>> instances.
>>
>> And, in fact the code above is valid in JDBC 2.0 and 3.0. If the driver
>> class name is in the system property "jdbc.drivers", then it will be
>> loaded automatically. Again I haven't looked to see how this handles
>> class loaders.
>>
>> Dan.
>>
>>

Mime
View raw message