Re: [stellation-res] Managing JDBC Drivers

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Mon, 2003-03-03 at 15:22, Jonathan Gossage wrote:
> 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.

We actually did this in an earlier version of the system, and it led to
some maintenance problems. Our decision at the time was that it wasn't
a good idea, and we were better off coding in database support
statically.

The problem involved upgrades. I'll give two examples of how we
got bitten.

(1) Postgres went from 7.0 to 7.1. The JDBC library was renamed from
   something like postgres-jdbc-7.0.jar to postgres-jdbc-7.1.jar. 
   When we upgraded our STellation install, the stellation jar directory
   now had two copies of the postgres-jdbc, and because the unix
   wildcard sorted alphabetically, the wrong one wound up first in the
   classpath.

(2) Xerces went from one jar to two different jars. By a similar process
  to the one above, we wound up with awful crashes, because the
  classpath wound up using the API jar from the newer xerces with the
  implementations from the older xerces.

Automatically generating classpaths from wildcards inevitably introduces
the possibility of these kinds of errors if the library set isn't
maintained perfectly.

If our install works to correctly set up the database that the user
selects, then the initial installation of the system scripts using
database-specific classpaths isn't difficult. It's my expectation that
people will be doing upgrades to their Stellation installation more
often than they switch databases, which is why I've pushed us in
the direction of hardening the classpaths to avoid upgrade problems,
at the cost of making multiple database support more cumbersome.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx