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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
