Uploaded image for project: 'CDI Specification Issues'
  1. CDI Specification Issues
  2. CDI-370

Expand @RequestScoped and @SessionScoped to account for WebSocket

    Details

    • Type: Feature Request
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      We've been testing injection into a WebSocket endpoint.

      @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope.

      However if you try to use the injected object from within the @OnMessage callback you get a Weld error:
      SEVERE: org.jboss.weld.context.ContextNotActiveException:
      WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

      Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback?

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            french_c Jens Schumann added a comment - - edited

            While the current CDI spec maintains a strong relationship between RequestScoped and HTTP i would not assume that RequestScoped is strictly bound to HTTP. The RequestScope spec/javadoc lists 4 use cases with one being bound to HTTP and another one that may hint a dependency to HTTP (because of JAX-RS, JAX-WS doesn't require HTTP). Especially it's availability in EJB method invocations and @PostConstruct tells me: RequestScopes lives without HTTP just perfectly.

            So RequestScoped should be available for WebSocket message delivery similar to the current JMS/@Asynchronous support.

            Personally I believe the sections "6.7.x {scope} context lifecycle" are already too verbose. I have no profound knowledge of the Java EE specification process, nevertheless I believe the scope lifecycle should be better covered by the Java EE umbrella spec similar to security and transactions (Java Platform, Enterprise Edition (Java EE) Specification, v7 and later). This way you can expanded the supported platform specs without touching the CDI spec again.

            Same applies to "2.4.1 Built-in scope types". The current wording "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7 represent the standard scopes defined by the Java Servlets specification." does not cover all supported use cases in 6.7.x and should relaxed (in a CDI 1.1 maintenance release i guess).

            Show
            french_c Jens Schumann added a comment - - edited While the current CDI spec maintains a strong relationship between RequestScoped and HTTP i would not assume that RequestScoped is strictly bound to HTTP. The RequestScope spec/javadoc lists 4 use cases with one being bound to HTTP and another one that may hint a dependency to HTTP (because of JAX-RS, JAX-WS doesn't require HTTP). Especially it's availability in EJB method invocations and @PostConstruct tells me: RequestScopes lives without HTTP just perfectly. So RequestScoped should be available for WebSocket message delivery similar to the current JMS/@Asynchronous support. Personally I believe the sections "6.7.x {scope} context lifecycle" are already too verbose. I have no profound knowledge of the Java EE specification process, nevertheless I believe the scope lifecycle should be better covered by the Java EE umbrella spec similar to security and transactions (Java Platform, Enterprise Edition (Java EE) Specification, v7 and later). This way you can expanded the supported platform specs without touching the CDI spec again. Same applies to "2.4.1 Built-in scope types". The current wording "The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined in Section 6.7 represent the standard scopes defined by the Java Servlets specification." does not cover all supported use cases in 6.7.x and should relaxed (in a CDI 1.1 maintenance release i guess).
            Hide
            meetoblivion John Ament added a comment -

            The difference here is that JMS explicitly notes the activation of the context. WebSocket spec makes no reference to any of the CDI contexts.

            Show
            meetoblivion John Ament added a comment - The difference here is that JMS explicitly notes the activation of the context. WebSocket spec makes no reference to any of the CDI contexts.
            Hide
            miojo Bruno Borges added a comment -

            [tracking]
            Related to WEBSOCKET_SPEC-196 (https://java.net/jira/browse/WEBSOCKET_SPEC-196)

            Show
            miojo Bruno Borges added a comment - [tracking] Related to WEBSOCKET_SPEC-196 ( https://java.net/jira/browse/WEBSOCKET_SPEC-196 )
            Hide
            miojo Bruno Borges added a comment -

            What is the status on this? Will there be an errata or something?

            Show
            miojo Bruno Borges added a comment - What is the status on this? Will there be an errata or something?
            Hide
            antoinesabot-durand Antoine Sabot-Durand added a comment -

            It’s the responsibility of Websocket spec to implement these scopes. We should ensure they take the point before closing the ticket.

            Show
            antoinesabot-durand Antoine Sabot-Durand added a comment - It’s the responsibility of Websocket spec to implement these scopes. We should ensure they take the point before closing the ticket.

              People

              • Assignee:
                antoinesabot-durand Antoine Sabot-Durand
                Reporter:
                jjsnyder Joseph Snyder
              • Votes:
                4 Vote for this issue
                Watchers:
                15 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Development