Francois Orsini wrote:
David, it looks good. Just a few comments.
* Regarding "Mixed Version Support", it might be good at some point to
elaborate on "As much as possible, two applications should be able to
use different versions of Derby within the same Java VM without having
to resort to creating specialized classloaders." - Were you referring to
2 different Derby engines or/and Clients or/and mix of the 2 running in
the same JVM? If an application is expected to run at a certain level of
Derby and it is not because of class order loading issues which could
cause the application not to use the appropriate level of Derby classes.
Depending what the statement meant I don't think we can completely rule
out specialized class loaders to isolate loading of a specific and
expected level of classes for certain configuration. More clarifications
on what the statement meant to say would be nice...
Hi, Francois. I'm not sure I fully understand your question, but let me
try to answer. The intent was that this was to cover the case where you
specifically want to run the network client at one version and the
embedded client at another. In this case you either have one
application with mixed version requirements or two applications running
in the same container with differing version requirements, in which case
you will need separate classloaders with separate classpaths. But
generally this is handled by the container provider environment and tools.
I would like to specifically talk about the first case -- a single VM
wanting to use a different version for the network client and the
embedded client. I can adjust the proposal (before I submit for another
vote) to try and be more explicit about this.
* As a guideline, we should try to have the <ComponentName>Info class at
the top level of the package for that component (in the case of Common
component, one would expect to have the class be defined under the
org.apache.derby.common package. I may have missed this being mentioned
in the proposal.
OK, seems reasonable.
* Would be nice to run JVM / Derby incompatibility test harness suite
when a new 'common' class is introduced (not just a new package).
I'm not sure why you'd want to run compatibility tests when adding new
classes and packages. The compatibility issue really comes up when you
modify an existing class, right?
Anyway, I don't know if it's essential to outline when compatibility
tests should be run as part of these guidelines...
+1
Thanks, but we'll need your vote again on the next go-round.
David
--francois
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
