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.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
