I think it should be possible to have many different implementations of the EJB container and the user(admin) should then decide which one he is using ...
Whilst I think it's a good idea not to be tied down to one specific system for eternity, I think that Sun's J2EE spec fairly badly split the EJB and Web containers.
As a result of which, pretty much every J2EE server thinks of the EJB container and J2EE container as being distinct. For example, IBM used to advise running Web containers on one node and EJB containers on another node.
I'm a strong believer that the distinction /shouldn't/ be split because of the terminology, but rather the EJB and Web should be in the /same/ VM process. It will drastically increase the performance of the inter-Web/EJB communication since you won't have to use RMI as an intermediary.
So, whichever the solutions are, they should be integrated in such a way that when you run a J2EE application, it runs in a single VM which provides both EJB and Web services. We should therefore use whichever containers support co-existence in the same VM, and not go for implementations which require being implemented in different VMs.
I also think that whilst some choice is good, too much can be detrimental. What I'd like out of an EJB server is one that 'Just Works' and I wouldn't be particularly bothered whether it used Tomcat/Jetty or OpenEJB/OJB. Nor would I (as an admin) bother about changing it.
IMHO it would be better to create a system that works well and quickly with one set of components (and here, other Apache projects certainly lend themselves) and not place as much importance whether parts of it can be changed.
Alex
