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 Fri, 02 Sep 2005 23:35:28 GMT
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?



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.

View raw message