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: VOTE: Shared Components Guidelines
Date Fri, 21 Oct 2005 23:19:44 GMT

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.

> --francois

View raw message