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: Sharing code
Date Sat, 03 Sep 2005 05:02:52 GMT
So, I've thought about this further, and here is what I like to 
propose.  Our guidelines and any framework we build for writing and 
using common code should allow for a consumer of a common component to 
fall back to reduced functionality if it so chooses, but it should also 
allow a consumer to raise an exception if it encounters a revision of 
the service that it can not work with.  We should recommend that all 
consumers work with at least one minor version prior to the current version.




David W. Van Couvering wrote:

> Given that the edge case we are talking about is where the user 
> intentionally wants to run the network client at a different rev than 
> the embedded client, it seems to me the user must know how to affect 
> the way the VM loads classes, otherwise they wouldn't be able to 
> accomplish this goal in the first place.
> That aside, I really do see this as a laudable goal, but technically I 
> can not get my head around how a consumer can manage the logic of 
> working in a degraded mode.  What if, for example, there are versions 
> 10.1, 10.2, 10.3, and 10.4 of a service, each one with increasingly 
> extended capabilities.  Does every consumer of this service need to 
> know how to work with each of these versions?  It seems to me that you 
> would need pluggable versions of the consumer, one for each version of 
> common code. So you would have this cascading effect of reduced 
> functionality services stacked on top of each other, and ultimately 
> wouldn't you end up with the entire network driver or engine running 
> at an old rev?  Doesn't this defeat the purpose of having mixed 
> versions running in the same VM?
> Thanks,
> David
> Daniel John Debrunner wrote:
>> David W. Van Couvering wrote:
>>> 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."
>> Also Rick said:
>>> o The exception would complain that the classpath was mis-wired and 
>>> explain how to wire it correctly.   
>> Just remember that classes get loaded into the JVM in more ways than the
>> class path variable, thus there may not be an easy way to describe how
>> to wire it correctly.
>> And what happens if there is no way for the user to reverse the order
>> the jars are searched? This is why a defensive approach is better, if I
>> don't have the functionality available then I continue to work but with
>> reduced functionality.
>> Dan.

View raw message