avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Sutic <leo.su...@inspireinfrastructure.com>
Subject RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Date Sun, 29 Sep 2002 19:54:07 GMT
Leo Simons wrote:
 > On Sat, 2002-09-28 at 15:26, Leo Sutic wrote:
 > >  + Avalon 4 contains the ComponentManager interface and thus
 > >    *all* component that claim to be Avalon 4 compatible MUST
 > >    support the Component interface.
 >
 > -1 on defining "avalon compatible component" this way. The whole point
 > of service.* is that you can have "avalon compatible components" that do
 > not implement Component!

Basic problem I have with your reasoning:

  + It is not OK for a container to not support Composable (i.e. explode when
    a composable component is loaded) and call itself 100% A4 compliant. This
    is because we may be in a situation when we have a legacy component, and
    we want that to work.

But this is only 1/2 of the contract: What are the rules for legacy 
*containers*?

In theory, if a container is 100% A4 compliant, it should remain so for all 
future
versions of A4, in the same way that a component, once having achieved 100% 
A4 status,
will remain so until A5.

The Seviceable interface messes all that up.

It is possible for a container to be Avalon 4.0 compliant, but not Avalon 4.1
compliant.

I consider this a problem.

What to do:

  + All Excalibur components that were released prior to the introduction 
of the
    Serviceable interface have to implement the Component interface until A5.

  + Any new releases must clearly state that they are targeted at A4.1 unless
    they implement Component, or if they use the service package.

  + ECM remains JDK1.2 compatible. Look, the damn thing is legacy legacy 
legacy.
    It works fine, but I'd rather have it remain A4.0 instead of trying to 
mutate
    it to A4.1, unless that mutation can be done without JDK1.3. Branching is
    another possiblity. Under JDK1.2, the lookup of a non-Component 
implementing
    component would throw a ComponentException, under 1.3 it would be solved
    via the proxy generator.

I think this solves Cocoon's problems.

I also think we can be a bit more bold with A4.2, seeing as the damage is 
already
done. Maybe we should take this chance to clean up, or even rename 4.2 to 5?

As for what the Serviceable interface is: I always considered it nothing 
more than a
method for Avalon component to access non-Avalon components via a unified
lookup mechanism.

Random thought: With the Proxy generator Berin put in the ECM, doesn't the 
whole
need for Serviceable disappear?

/LS




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message