Re: [stellation-res] Managing JDBC Drivers

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
Sent: Tuesday, March 04, 2003 10:59 AM
Subject: Re: [stellation-res] Managing JDBC Drivers


> 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
>
It seems that you are dammed if you do and dammed if you don't :-).
Personally I think that there are equal but different amounts of trouble at
the end of each path. Given the lack of good infrastructure, robust
installation/upgrades are hard to achieve.

In any case for the moment, I will go with your approach and see if I can
come up with or find something better for later.

Regards

Jonathan