> I think the current experimentations with multiple containers
> lets us push things into different directions to see what
> we may want from that ubercontainer.
I think that multiple containers help to promote portability based upon the
design contracts instead of the semantics of individual implementations.
There is a difference between building an ubercontainer, and implying that
other containers are no longer valid. That appears to be the way that this
conversation is being perceived in some corners, and there are people here
who clearly have emotional investments in multiple containers which only
results in disquiet.
If you want to suggest that a goal be to implement a reference
implementation that scales from J2ME to J2EE, and from an heavyweight
application container to a lightweight beanbox, fine. But I don't see that
as a near or even mid-term reality. Furthermore, it does not eliminate the
stated desire (requirement, IMO) for portability based upon contract, not
implementation, so the hypothetical ubercontainer cannot be in lieu of
supporting multiple containers, and should not be presented as such.
Make sense?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
