Better define integration with EJB and CDI

[glassfishrobot]

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.

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/websocket-spec/issues/197
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek

[glassfishrobot]

@glassfishrobot Commented Reported by reza_rahman

[glassfishrobot]

@glassfishrobot Commented panga said: The answer is No for question number 4 for Java EE 7 compliant app servers (Glassfish and Wildfly). See #238

[glassfishrobot]

@glassfishrobot Commented @pavelbucek said: The intention was not to have the question answered "right now" - it was meant as a guide to what should be improved in the (websocket) spec in regards to Java EE / CDI integration.

I already linked your issue to this one, see "Issue links" section.

[glassfishrobot]

@glassfishrobot Commented Issue-Links: blocks TYRUS-410 blocks TYRUS-260 is related to WEBSOCKET_SPEC-238 TYRUS-281

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA WEBSOCKET_SPEC-197

[jansupol]

+1 for better integration with CDI. -1 for EJB, the community around EJB seems to be smaller every day, Jakarta EE 9 already pruned some parts of it, I will be curious what Jakarta EE 10 brings to EJB.