Leo Sutic wrote:
> 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*?
Calm down. ECM supports Composable. It supports Serviceable (at lower
levels than itself). The problem is that if the component supplied by
ECM does not implement Component, then that component is not accessible
to any Composable. The dynamic proxy fixes that.
> 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.
ECM has been made A4.1 compliant. A4.1 is *released*.
> 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:
>
> + 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.
Why JDK 1.2? When there wasn't a 1.3+ for certain platforms it made
sense.
> I think this solves Cocoon's problems.
Not everyones.
> 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?
No. 4.2 is not 5, there is no 4.2.
> 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?
Random thought: If we are trying to divorce ourselves from the need of
the Component interface (i.e. migrate to Serviceable) doesn't the need
for the ProxyGenerator dissapear? The trend should be simplification,
not making things more complex. Any complexity should have a reason.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
