Better define integration with EJB and CDI

One of the items I would like to see better addressed in a future WebSocket API version is integration with EJB and CDI.

The case for CDI integration is likely fairly self-explanatory so there no point repeating it. However, perhaps it is important to make the case for EJB integration. Direct EJB integration is a very good fit for RAD code where transactions, persistence, etc are used directly in a WebSocket service. Now while much of this functionality is available outside EJB, some of it is not such as thread safety, asynchronous processing and scheduling. Specifically it may be important to hash out the following questions:

1\. Do stateless session beans map to WebSocket endpoints (the likely answer is no)?
2\. Can stateful session beans be WebSocket endpoints? I think the likely answer is yes if you treat the WebSocket session as an EJB session, hence having a stateful session bean instance per remote client. @Remove could be called automatically when the WebSocket session is closed (just like CDI conversations).
3\. Can singleton session beans be WebSocket endpoints? I think the likely answer is yes and it would provide very useful thread safety services across all remote clients on an endpoint (that can be fine tuned as needed).
4\. Is the caller Principal passed on to EJB from WebSocket (I think the answer is yes)?
5\. WebSocket could have some really nice synergy with @Asynchronous.
6\. What methods can overlap with @Schedule, EJB life-cycle callbacks and other remote/local end-points?

There are similarly interesting questions to address as to CDI integration:

1\. Will @Transactional work in a WebSocket endpoint? How about @Observes, @Stereotype, @Produces, @Disposes, etc?
2\. Perhaps @Dependent could fit per-peer model?
3\. @ApplicationScoped/@Singleton would be a good fit for a shared endpoint model.
4\. @ConversationScoped, @RequestScoped probably do not map well to WebSocket.
5\. I think @SessionScoped would be a great fit for a instance per-peer model, provided HTTP session ~= WebSocket peer.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.

No source file or test is named. Start by reviewing the WebSocket API context and the EJB and CDI integration questions listed here, then identify a specific, agreed specification change; done would require settled scope rather than an open-ended set of design questions.

Written by the indexing model from the issue text.