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.
Thoughts?
Thanks,
David
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.
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
