db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Sharing code
Date Fri, 02 Sep 2005 20:52:06 GMT


David W. Van Couvering wrote:
> Yes it's true that we can't control the ordering of a classpath, and we 
> do need to address this.  However, most version policies I have worked 
> with let an old version of a consumer work with a new version of 
> producer, but if a new version of consumer tries to use an old version 
> of producer it gets an exception.  Even today if a new version of Derby 
> finds an old version of a database file, it performs some form of 
> upgrade before it will work with it (right?) rather than continuing to 
> work with the old format (right?).
> 
With soft upgrade no upgrade is done, the code must work with the old
format, so that a previous version of the server can still access the
database.  With respect to database files, we never expect an old
server to be able to access a "new" format - so once you allow
hard upgrade "upgrade=true", you can't go back.

> Maybe you have an idea of how to make it easy to accomplish, but as far 
> as I can see, it's a big burden on the developers of consumer classes to 
> know how to "work with" older versions of common services, especially 
> when this type of configuration (with mixed versions of jar files) is 
> such an edge case.
> 
> That said, I think it's not right for the user to get some strange 
> NoSuchMethodException when the new consumer tries to use a method that 
> doesn't exist in the old producer.  So it seems to me we need some type 
> of service manager (I'm not committing to which one yet, I need to do 
> some investigation) that allows you to say something like "give me an 
> implementation of this interface at this version level or higher".  If 
> the service manager says "I don't have that" then we can throw an 
> exception saying something like "Unable to load version 10.2 of the 
> Message Service.  It is probable that your classpath has older versions 
> of Derby jar files listed first; please check your classpath and make 
> sure that all Derby jar files are listed ahead of older versions."
> 
> David
> 
> Daniel John Debrunner wrote:
> 
>> David W. Van Couvering wrote:
>>
>>  
>>
>>> Hi, all.  Yes, it's your favorite topic.  :)
>>>
>>>   
>>
>>
>> [snipped - good shared code proposal]
>>
>>  
>>
>>> The common classes will be placed into both derby.jar and
>>> derbyclient.jar.  When you have a classpath with a network client at one
>>> revision and the embedded driver at another revision, the jar with the
>>> highest revision should always go first,
>>>   
>>
>>
>> The issue is how to enforce that. I think it's impossible to enforce
>> that or guarantee any class path ordering. Remember class path problems
>> are by far the leading cause of technical support calls related to Java
>> programs.
>>
>> What it means is that the interface needs to have a version number that
>> can be obtained easily, and thus the caller must only use the interface
>> to the level offered. If a caller was written against version 3, but
>> only version 2 is available then it can only use version 2 functionality.
>>
>> Dan.
>>
>>  
>>


Mime
View raw message