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.
