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*?
>
> 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.
Agreed.
>
>
> The Seviceable interface messes all that up.
Disagree.
>
> It is possible for a container to be Avalon 4.0 compliant, but not
> Avalon 4.1
> compliant.
Yep.
>
> 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.
+1
>
>
> + Any new releases must clearly state that they are targeted at A4.1
> unless
> they implement Component, or if they use the service package.
+1
I was thinking about exactly the same thing yesterday in relation to the
Cocoon discussions.
>
>
> + 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.
Is the ECM (CVS version) support for Serviceable based on proxying the
interface? Is so, is there any reason why the ECM cannot simply be
updated to handle serviceable components the good old fashined way (if x
instanceof Serviceable ... )?
>
> 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?
I think 5 is way too dramatic - but a 4.2 is valid with respect to
deprecation of Component et. al. and makrer interfaces.
>
>
> 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.
Nothing less!
>
>
> Random thought: With the Proxy generator Berin put in the ECM, doesn't
> the whole
> need for Serviceable disappear?
Urggh #&$
That's a hack - the approach you outlined above is the right one -
recognition of the implications of version and respectin this in terms
of the components that have been released, combined with rigerouse
documentation of future component releases.
Cheers, Steve.
>
> /LS
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
