db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: VOTE: Shared Components Guidelines
Date Fri, 21 Oct 2005 23:44:49 GMT
On 10/21/05, David W. Van Couvering <David.Vancouvering@sun.com> wrote:
> 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.

> > --francois
> >
> >

View raw message