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.
