geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sisson (JIRA)" <>
Subject [jira] Created: (GERONIMO-631) Package Derby tools with Geronimo
Date Fri, 15 Apr 2005 01:17:17 GMT
Package Derby tools with Geronimo

         Key: GERONIMO-631
     Project: Geronimo
        Type: Improvement
    Reporter: John Sisson
    Priority: Minor

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... 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.


This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message