[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[stellation-res] Managing JDBC Drivers
|
One of the problems with our current build/install/execute environment for
command line and server components is that we hard code the name of the
Postgres JDBC Jar file in the various scripts and leave it to the end user
to make appropriate modifications. I believe that we should treat all
potential JDBC drivers as equals and I think I may have found a simple way
to manage this.
The basic problem to be solved is that the Jar file paths must be in the
command line -classpath specification when a launch script is invoked.
Currently we construct this path when we build the source code for the
system by editing pro-forma versions of the launch scripts. This means that
the user has to edit the launch scripts after installation if not using
Postgres.
My proposed solution relies on the fact that all the jars required for
launching are stored in ${user.home}/stellation/lib by the installation
procedure and that the launch scripts are in a known relative path from this
directory. Accordingly it is easy to have the launch scripts generate the
required -classpath specification at script invocation time by enumerating
the Jar files in ${user.home}/stellation/lib.
I have done a proof of concept implementation for Windows using standard
Windows batch file capabilities and it works reliably. If we were to use
this technique, all that the user would need to do is to install the needed
Jar files for the chosen JDBC driver(s) in ${user.home}/stellation/lib and
the classpath would be automatically and correctly constructed at launch
time. This is similar to the deployment support provided for EJB's by JBOSS.
Any thoughts on this as a way of handling JDBC driver deployment?
Incidentally the same deployment technique will work if we want to add
plugin capabilities to command-line and server components that run outside
of Eclipse.
Regards
Jonathan