CDI Specification Issues
  1. CDI Specification Issues
  2. CDI-370

Expand @RequestScoped and @SessionScoped to account for WebSocket

    Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Major 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?

        Activity

        Hide
        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
        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
        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
        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
        Bruno Borges
        added a comment -

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

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

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

        Show
        Bruno Borges
        added a comment - What is the status on this? Will there be an errata or something?
        Hide
        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
        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:
            Antoine Sabot-Durand
            Reporter:
            Joseph Snyder
          • Votes:
            3 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: