websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-100

Clarify semantics of EJB SSB and Singletons and CDI managed beans - as-websockets

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      as synopsis. Am working with Marnina to determine any other restrictions.

        Activity

        Hide
        dannycoward added a comment -

        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.
        Show
        dannycoward added a comment - 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.
        Hide
        dannycoward added a comment -

        Websocket endpoints in Java EE containers can have things injected into them, just like the other web components like servlets, JSP beans etc

        Show
        dannycoward added a comment - Websocket endpoints in Java EE containers can have things injected into them, just like the other web components like servlets, JSP beans etc

          People

          • Assignee:
            dannycoward
            Reporter:
            dannycoward
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: