Re: [stellation-res] Managing JDBC Drivers

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

On Tue, 2003-03-04 at 13:01, Jonathan Gossage wrote:
> ----- 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.

That's exactly my conclusion. We've got a hard-to-solve problem, and the
straightforward ways of solving it both stink. I keep hoping for a
brainstorm about how to solve this kind of thing. The best I can come up
with is to trust Eclipse - that is, when we manage to make the switch to
an all-plugin architecture, the database support components will become
independent plugins, and a lot of the Eclipse infrastructure was
designed to deal with precisely these kinds of issues. But for the
moment, it does nothing to help us. 

	-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