db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: VOTE: Principles of sharing code
Date Wed, 02 Nov 2005 18:43:22 GMT
This is correct, except I think limiting it to "classpath" may cause 
confusion in some environments.  See for example Bryan's struggles 
because he had a Derby jar file in $JAVA_HOME/lib/ext, which takes 
precedence over the classpath.

You might say something more general like "ensuring that the higher 
revision level jar is first in the order that classes are loaded (e.g. 
by placing it first in the classpath) will make the functionality and 
bugfixes from the higher revision level available"

Also, it's possible that the higher revision functionality is still 
visible *if* it's from a package that doesn't exist in the older 
revision of the common code.  For example, if you add 
org.apache.derby.common.foobar to revision 1234 and this package is not 
in revision 1233, then the classes in foobar will be visible regardless 
of classpath ordering.  This is *not* the case if you add new classes to 
an existing package, as classes for a given package can not be loaded 
from multiple jar files if the packages are sealed (which I'm assuming 
is the case for common packages).  Do I have that right?

Also, you don't talk about upgrade scenarios, where the bugfix is there, 
but then someone upgrades and all of a sudden the bugfix is gone.  This 
can *only* occur if (a) the bug fix is in a new package and thus visible 
even though the jar file doesn't have precedence and then (b) the 
upgrade places the jar file with most precedence at a revision level 
that has the new package but *not* with the bugfix.  e.g.:

version 1234 has a new package, common.foobar
version 1233 does *not* have common.foobar

jar ordering is 1233:1234

1234 is upgraded to 1234.1 which has a bug fix in common.foobar, so now 
you have


and all is good

then 1233 is upgraded to 1234 and you have


and the bugfix "disappears"


Kathey Marsden wrote:
> David W. Van Couvering wrote:
>>Thanks, Dan.  I would like to know if we need to have a vote on the
>>overall principles of shared code or if people just want to see an
>>examlpe implementation.  I am fine either way, although personally I'd
>>like to make sure we agree on the principles before I spend too much
>>time on an implementation.
> I think the requirement for a vote, be it in principle or patch  comes
> primarily from the resulting product behaviour changes. I think for the
> changes  you have proposed, that means  reduced support for mixing
> server and client jar versions.  I think I finally understand the change
> in a way that I can explain it to users and support folks that are
> affected by it  but know nothing about the internals of Derby, what's
> shared or how,  and I think it goes like this:
> Behaviour Change:
> Derby will continue to allow  mixing different versions of
> derbyclient.jar and derby.jar in the same JVM classpath but beginning
> with Derby 10.2 this capability will be affected by classpath order.  If
> the lower revision level jar  comes first in the classpath,  new
> functionality and bug fixes may not be available, but functionality at
> the lower revision level will not be affected.  Placing the higher
> revision level jar first in the classpath will make the functionality
> and bugfixes from  the higher revision level available. 
> Example:
> If a bug is fixed  in version (1235)  and  a single JVM has a
> client application  with version (1234) derbyclient.jar  and 
> an embedded application with (1235) derby.jar in it's
> classpath,  it may be necessary to either upgrade  the client version
> to (1235) or   make sure  derby.jar is first in the classpath 
> for the embedded application to see the fix.
> Does this sound like an accurate description of the behaviour change
> from the user/support  perspective?    Is there anything else we should
> watch out for in environments where jar versions are mixed?  Will
> derbytools.jar be affected?  Just to be clear, I am not challenging
> anything here.  I'm  just trying to understand and make sure I explain
> this to others correctly and deal with it properly from a support
> perspective.  
> Thanks
> Kathey

View raw message