Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mcintyre.a@gmail.com designates
 64.233.182.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OzV5KCuv5t5gYwHy6+jZSejtFAdzcXSSsi9CM/741zCKnAPol7Wp5Kpg1i7x9lbbbR3hVNxZy1L9b1cp0PD36+1KAJ9qi3/Dp6oeOqyJHYhVw5z019mzJ6uTOwSygibEAxdtm5DvCBY61b3eexKyDSNT1B5PlTe4YhXc5PjyDjo=
Message-ID: <54ac72d70602282216h3967a580o2622f75805f04a7d@mail.gmail.com>
Date: Tue, 28 Feb 2006 22:16:27 -0800
From: "Andrew McIntyre" <mcintyre.a@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: derbytools.jar loading derbyclient.jar
In-Reply-To: <44053257.9090307@sbcglobal.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <44034D3D.4050904@sbcglobal.net>
	 <54ac72d70602271221q576af892k3eb821d423a31101@mail.gmail.com>
	 <44036039.6030708@apache.org> <4403611E.1080505@sbcglobal.net>
	 <54ac72d70602271626oa68627bvd9b3bb7f32fdd637@mail.gmail.com>
	 <4403A405.1050504@sbcglobal.net>
	 <54ac72d70602281658q776cd029of5e359d143cd8aad@mail.gmail.com>
	 <44051E29.2090904@sbcglobal.net>
	 <54ac72d70602282049h4122b4e4qf9cea3521613b6c7@mail.gmail.com>
	 <44053257.9090307@sbcglobal.net>

On 2/28/06, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
>
> See  Mixed Version Support at:
> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines

That page describes how shared components should behave in a mixed
version environment, but let's look at the contract:

*Two applications should be able to use one version of the Derby
network client driver and a different version of the Derby embedded
driver within the same Java VM without having to resort to creating
specialized classloaders.

This would still be true, but care must be taken to put derbytools.jar
after any older derby.jar/derbyclient.jar you would like to use.

*Older versions of Derby jars will get their expected behavior in a
mixed version environment regardless of jar ordering.

This would not be true, if derbytools.jar is in the same location as
derby.jar/derbyclient.jar and first in the classpath. The older jar
would need to come first. BUT, this statement was agreed upon based on
talking about shared components and how the functionality in shared
environments would behave. Your concern may apply equally in this
case, and I'm curious if it does.

Note that the result would not be anomalous behavior by shared code:
you just get the newer driver, not unlike the situation now if, for
example, a newer version gets put in jre/lib/ext and the user puts an
older one on the classpath. (which means getting sysinfo to report
these situations is imperative)

*Newer versions of Derby jars will get new behavior if the newer jar
files are loaded first, and older behavior if the older jar files are
loaded first.

This would be true, although this statement is very specific to shared
components. In general new jars first =3D new behavior/new drivers, old
jars first =3D old behavior/old drivers.

Note that this change has no actual impact on the functionality of
either client or engine, only on the resultant classpath when
derbytools.jar is loaded.

So:

> > For currently releases that would mean:
>
> 10.1 derby client.jar  with  10.2  derby.jar
> 10.2 derby.jar with 10.1 derby client.jar

These combinations would be unaffected - if that's all you have in
your classpath. if we expand that with the tools jar, and assume
derby.jar/derbyclient.jar are in the same place as tools:

10.2 tools : 10.1 client : 10.1 engine =3D 10.2 client / 10.2 engine
10.1 client : 10.2 tools : 10.1 engine =3D 10.1 client / 10.2 engine
10.1 derby : 10.1 engine : 10.2 tools =3D 10.1 client / 10.1 engine

Of course, I'm not sure what sort of usage (outside of our tests)
would lead to such a pattern as the above. I'd expand with e.g. 10.2
derby.jar in there, but that would lead to far too many premutations
to stick in an email. But you get the idea.

How are we assuming classpath is being set for the JVM that would lead
to mixed versions in the classpath? By two different applications'
installers? By being in a library directory in which all jars are
added to the classpath? By the various extension loading mechanisms?
Via app server classloaders and .war files? All of the above? I'm just
trying to get a handle on the types of situations that would lead to
jars of mixed versions being in the classpath so that I can understand
the risks that would be present.

thanks,
andrew