geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sisson (JIRA)" <...@geronimo.apache.org>
Subject [jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo
Date Sat, 23 Jul 2005 00:37:53 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]

John Sisson updated GERONIMO-631:
---------------------------------

    Fix Version: 1.0-M5
    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

  was:
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

        Version: 1.0-M4
    Environment: 

Waiting for Derby 10.1 to be released.

> Package Derby tools with Geronimo
> ---------------------------------
>
>          Key: GERONIMO-631
>          URL: http://issues.apache.org/jira/browse/GERONIMO-631
>      Project: Geronimo
>         Type: Improvement
>     Versions: 1.0-M4
>     Reporter: John Sisson
>     Assignee: John Sisson
>     Priority: Minor
>      Fix For: 1.0-M5

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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message