Minor Description
IBM now has donated the JDBC network driver code to the Derby project (as a patch) and it is under review (not committed). Once it has been accepted and included in a formal Derby release, it would be worthwhile including it with Geronimo, along with some simple scripts to invoke Derby's ij tool, so Geronimo users can easily manage the embedded Derby database(s).
FYI.. the donated JDBC network driver supports XA.
Here is a mail thread titled "Provision of derby tools JAR and JDBC network driver JAR" from the dev list...
sissonj@insession.com wrote:
> If a Java application (not J2EE app) provides a database creation utility
> and expects to be able to use a JDBC network driver to connect to the
> Derby network server embedded in Geronimo, then currently the command line
> application (the database creation utility) needs access (assuming the IBM
> Universal Driver is used) to db2jcc.jar and db2jcc_license_c.jar .
>
> On the Derby lists I saw that IBM is planning on donating a JDBC network
> driver sometime in March.
>
> Q1. Would it make sense to place this driver jar and the derbytools jar in
> the geronimo/repository/incubator-derby/jars directory to accompany the
> other derby jars so we provide all the required jars needed for connecting
> to and administering the Derby database embedded in Geronimo (even though
> the driver or tools won't be loaded by Geronimo)?
>
Yes - we already configure and start the network server so having the
client jars available would make sense. These could also be used to
connect to a Derby instance in a different JVM.
> Q2. Even if we do provide all the JARs in the repository, users of a
> command line Java application (running on the same machine) would probably
> have to edit their classpath to point to the correct version of JDBC
> driver that matches the version of Derby embedded in Geronimo. Any
> suggestions on how this could be automated (determining the version and
> getting the driver JAR)?
>
I think it would depend on how the client app expected this to work and
whether it relied on having them in the system classpath or did some
fancy uber-jar type thing.
One option would be to deploy the client along with the server (EAR) as
a J2EE Application Client. IIRC the app client can have a plan
associated with it where they can specify dependencies just like with
server-side modules.
–
Jeremy