> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> Leo Sutic wrote:
> > 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*.
I'm fully aware of that. But my point is that instead of having
just Avalon 4, we have Avalon 4.0, Avalon 4.1, and we'll have Avalon
4.2,
and the frameworks will be sufficiently different that a container
written
for Avalon 4.0 will not be completely Avalon 4.1 compliant.
That's fine, if you can committ resources to playing catch-up with an
evolving standard, but the whole point of a framework is that you should
not *have* to play catch-up.
Now I'm all for evolving specifications, but it is a fact that the
framework that claims to be most fundamental for everything (i.e. you
would
use Avalon to build an EJB server), is also the framework that has
changed
the most, and that has consumed most of my catch-up resources.
That is my problem and not yours - but to dismiss the problem with a
"A4.1 is *released*" is just not right. It assumes that once the gods at
avalon-dev releases a new version, the rest of the world had better
keep up or they will, can and should be left behind.
> > 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.
As long as Cocoon promises to run on JDK1.2, we have to support it.
> > I think this solves Cocoon's problems.
>
>
> Not everyones.
I don't get your point.
> > 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.
That depends on how you define compatibility between Avalon versions,
what you prioritize, etc.
*Can* we remove loads and loads of cruft from Avalon? Sure.
*Should* we remove loads and loads of cruft from Avalon? Not so sure,
since
we have to consider compatibility.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
