db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: derbytools.jar loading derbyclient.jar
Date Mon, 27 Feb 2006 20:20:47 GMT
Kathey Marsden wrote:

> Andrew McIntyre wrote:
> 
> 
>>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...
>>
>> 
>>
> 
> Could it possibly only load it iff no other derbyclient.jar  is 
> available? 

Just to be clear, the Class-Path attribute does not load the jar, it
merely adds it to the class path.

With a classpath like this:

d10_1/lib/derbyclient.jar:d10_2/lib/derbytools.jar

prior to 1019 change the classpath would remain unchanged,
now it becomes:

d10_1/lib/derbyclient.jar:d10_2/lib/derbytools.jar:d10_2/lib/derby.jar:d10_2/lib/derbyclient.jar

That (I believe) does not change behaviour, however if the user's
classpath is reversed, then a different client will be picked up.

User's classpath

d10_2/lib/derbytools.jar:d10_1/lib/derbyclient.jar

actual class path

d10_2/lib/derbytools.jar:d10_2/lib/derby.jar:d10_2/lib/derbyclient.jar:d10_1/lib/derbyclient.jar

Once sysinfo is fixed, then it would be clear that the 10.2 client is
being selected.

(note, any jars from Class-Path manifest attribute that do not exist are
not added to the classpath).

Dan.


Mime
View raw message