db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: derbytools.jar loading derbyclient.jar
Date Mon, 27 Feb 2006 19:31:20 GMT
On 2/27/06, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
> >derbytools.jar will automatically put derbyclient.jar in the
> >classpath. Since you have derbytools.jar from trunk before
> >derbyclient.jar version 10.1 in your classpath, derbyclient.jar will
> >be shadowed. Sysinfo will however report that you are using the 10.1
> >version of derbyclient.jar, since it only sees the CLASSPATH variable.
> What Jira was this added under?


> Is this really a good idea?

Only if you want to be able to execute one of the tools with java -jar
derbytools.jar and be able to use it with a client connection without
setting up the classpath. But now that I think about it, probably not
since who knows how many people's applications already have classpath
set up a particular way, although it's only a problem in a mixed jar

> It seems bad to me that I set up my CL:ASSPATH to get one client and derbytools
> decides to give me another one.  Then  with DERBY-668 sysinfo tells me I
> have the one I want.

It certainly underscores the need to get DERBY-668 fixed. And when it
is fixed, we should take care that we show which jar is actually
taking precedence.

I hadn't considered the mixed jar environment, sorry, and I guess
there's no choice but to take out the Class-Path attribute from
derbytools.jar. Sadly, it cripples the spirit of 1019: there is then
no direct path to using the tools and one must explain classpath
before using the tools. Ah well, so it goes...


View raw message