What I think we have concluded is that we want websocket endpoints to be non-contextual managed beans. This is described in the Java EE spec (public draft, v7) EE 5.24.
In this case, other EE components can be injected into websocket endpoints. So the need for websocket endpoints to BE EJBs or managed beans themselves is greatly reduced: instead of using EJB/CDI services by being one, you can delegate to one very easily.
We may look at how to leverage the EJB model more directly in a future release.
Stateful session beans and singletons look like a good match with websocket endpoints, but:
- we'd want singleton EJBs-as-websockets to be flagged Lock(LockType.READ) so that it recieved concurrent calls instead of getting them one-at-a-time from multiple clients.
- we'd want some way to relax the restriction that websocket endpoint instances that were stateful session beans were removed whenever any of the methods threw a runtime exception.