On 10/21/05, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
Yes please - I was just trying to say that the current proposal is not going to be the panacea where specialized class loaders would be required for _certain_ (mixed) configuration of network client drivers (various ones with different versions in the same JVM) and derby engine version would happen to run in an app server which would not necessary install separate class loaders for the 2 applications (i.e. HomeGrown ones)...
Yes, you're right - Even if a newly added class to the common package area gets referenced by other classes already in the same package, them the modification rule will apply since they would have had to be modified in order to reference the new class ;)
Will do - thanks.
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.
Yes please - I was just trying to say that the current proposal is not going to be the panacea where specialized class loaders would be required for _certain_ (mixed) configuration of network client drivers (various ones with different versions in the same JVM) and derby engine version would happen to run in an app server which would not necessary install separate class loaders for the 2 applications (i.e. HomeGrown ones)...
>
> * 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?
Yes, you're right - Even if a newly added class to the common package area gets referenced by other classes already in the same package, them the modification rule will apply since they would have had to be modified in order to reference the new class ;)
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.
Will do - thanks.
David
> --francois
>
>
