WebSocket Spec does not define the activation requirements of CDI Contexts

[glassfishrobot]

Currently, a few issues are floating around regarding WebSocket spec and the activation (or lack there of) of CDI contexts. As was the case for the JMS spec & the JSF spec, the WebSocket spec must define what the activation is for CDI contexts when it comes to its methods. For example, "managed bean" is only mentioned once in the PFD however its notion is ambiguous:

Some of the non-api features of the Java WebSocket API are optional when the API is not implemented as part of the full Java EE platform, for example, the requirement that websocket endpoints be non-contextual managed beans (see Chapter 7). Such Java EE only features are clearly marked where they are described.

There is nothing in Chapter 7 that mentions "managed bean" as indicated in this chapter. So in my opinion, I think it's needed for the WebSocket spec to spell out that it expects Request Scope to be enabled during an @OnMessage method, and as a result must ensure that the context is initialized when the method is called.

Affected Versions

[1.0]

[glassfishrobot]

@glassfishrobot Commented
Reported by genomeprjct

[glassfishrobot]

@glassfishrobot Commented
Issue-Links:
blocks
TYRUS-260
is related to
JMS_SPEC-121
TYRUS-281

[glassfishrobot]

@glassfishrobot Commented
ggam said:
Any chance to get a MR for Java EE 8 clarifying CDI integration?

[glassfishrobot]

@glassfishrobot Commented
@pavelbucek said:
Can you please start this thread at [email protected] instead of here?

Thanks!
Pavel

[glassfishrobot]

@glassfishrobot Commented
ggam said:
Done! My email is now waiting for editor's approval

[glassfishrobot]

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

[glassfishrobot]

@mrts Commented
@pavelbucek I think it's a high time to discuss this now that Java EE 8 spec is taking shape. Where should the discussion happen now that java.net is retired?

It's especially confusing that there is no clearly defined relation to @SessionScoped beans and security context propagation, see related issues: #197, #238, #215 and https://issues.jboss.org/browse/WELD-2028, vaadin/cdi#88, vaadin/framework#8967, question in StackOverflow.

Would the following example serve as acceptance criteria?

// -- UserPreferences.java
@SessionScoped
class UserPreferences {
    ...
}

// -- QuoteEJB.java
@Stateless
@RolesAllowed("users")
public class QuoteEJB {
    ...
}

// -- QuoteWebSocketServer.java
import javax.websocket.server.ServerEndpoint;
import javax.annotation.security.RolesAllowed;
    
@ServerEndpoint("/actions")
@RolesAllowed("users") // Doesn't actually work
class QuoteWebSocketServer {

    @Inject // Doesn't actually work
    private UserPreferences userPreferences;

    @EJB // Doesn't actually work
    private QuoteEJB quoteEJB;

    @OnMessage
    public void handleMessage(String message, Session session) {
        final List<Topic> topics = userPreferences.getSubscribedTopics();
        final List<Quote> quotes = quoteEJB.getQuotesForTopics(topics);
        ...
    }
}

[glassfishrobot]

@mrts Commented
The discussion is happening at https://javaee.groups.io/g/websocket-spec/topic/websocket_spec_security_and/5842413

[glassfishrobot]

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