You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "John Sisson (JIRA)" <de...@geronimo.apache.org> on 2005/04/15 03:17:17 UTC
[jira] Created: (GERONIMO-631) Package Derby tools with Geronimo
Package Derby tools with Geronimo
---------------------------------
Key: GERONIMO-631
URL: http://issues.apache.org/jira/browse/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...
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "David Blevins (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]
David Blevins updated GERONIMO-631:
-----------------------------------
Fix Version: 1.0
(was: 1.0-M5)
> 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
>
> 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
[jira] Closed: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "Matt Hogstrom (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]
Matt Hogstrom closed GERONIMO-631.
----------------------------------
Fix Version/s: 1.1
(was: 1.2)
Resolution: Fixed
Old issue
> Package Derby tools with Geronimo
> ---------------------------------
>
> Key: GERONIMO-631
> URL: http://issues.apache.org/jira/browse/GERONIMO-631
> Project: Geronimo
> Issue Type: Improvement
> Components: databases
> Affects Versions: 1.0-M4
> Reporter: John Sisson
> Assigned To: John Sisson
> Priority: Minor
> Fix For: 1.1
>
>
> 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
[jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]
John Sisson updated GERONIMO-631:
---------------------------------
Fix Version: 1.1
(was: 1.0)
> 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.1
>
> 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
[jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ 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
[jira] Assigned: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]
Dain Sundstrom reassigned GERONIMO-631:
---------------------------------------
Assign To: John Sisson
Good idea. Thanks for volunteering :)
> Package Derby tools with Geronimo
> ---------------------------------
>
> Key: GERONIMO-631
> URL: http://issues.apache.org/jira/browse/GERONIMO-631
> Project: Geronimo
> Type: Improvement
> Reporter: John Sisson
> Assignee: 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...
> 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
[jira] Commented: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=comments#action_12359512 ]
John Sisson commented on GERONIMO-631:
--------------------------------------
Need the other derby jars in the repository shipped with Geronimo + supply scripts in invoke derby's ij tool.
> 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.1
>
> 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
[jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo
Posted by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ]
Dain Sundstrom updated GERONIMO-631:
------------------------------------
Component: databases
> Package Derby tools with Geronimo
> ---------------------------------
>
> Key: GERONIMO-631
> URL: http://issues.apache.org/jira/browse/GERONIMO-631
> Project: Geronimo
> Type: Improvement
> Components: databases
> Versions: 1.0-M4
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Minor
> Fix For: 1.2
>
> 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