[cdi-dev] Today's meeting agenda

[Stuart Douglas]

So I thought I would write up my thoughts on the web socket scoping issue here, to save some time on the call. 

Basically with Websockets + @RequestScope I think there are really 4 options:

1) Disallow it altogether. I think we can all agree that this is not particularly useful. 

2) One request scope per connection. I don't really think that this makes much sense either. It does not make sense to classify a long lived web socket connection as a 'request'. 

3) One request scope per web socket message. This basically means that every incoming message has its own request scope associated with it (note that message != frame, so continuation frames share the request scope of the first text or binary frame). In some cases @OnMessage endpoints can be called multiple times per message, so the request scope will live longer than the life of the method invocation. It is also possible to have multiple request scopes active at one time, as you can receive control frames in the middle of fragmented messages (e.g. your @OnMessage method for a pong frame could be called while in the middle of receiving a fragmented text message). 

I think this makes the most sense. 

4) One request scope per method invocation. In most cases this will be equivalent to #3, the only difference occurs if the user is receiving partial messages. In this case you would end up with multiple request scopes per message. I don't think this makes much sense, as the container can break up messages however it wants to, so in some cases a message could be processed in a single request, in other cases it could have several different request scopes associated with the same message. With this approach there is only one request scope active at a time for a given connection, and request scopes are very short lived, although I don't think that really matters.


With regard to session scope:

So again there are a few possibilities:

1) Disallow it altogether. 

2) Disallow it altogether except for in the @OnOpen method, where it corresponds to the HTTP session. 

I think this approach makes the most sense. The @OnOpen method is executed in the scope of a normal HTTP request, so you would expect that the existing request and session scopes would be available. I think if we go this route we should also introduce an @WebSocketConnection scope (or whatever) for objects that are scoped to the connection. 

3) Allow it, so you can access the HTTP session from web socket methods. 

This is kinda ok, but has some issues:
- The session might expire while the connection is active, as web socket messages don't prolong the life of the session
- This will require container integration, which means that this cannot be implemented purely using the servlet API's. Basically there is no guarantee that the session object you get in a request will be usable after that request is finished. For simple in memory based implementations this will probably work fine, if the session is backed by a clustered session manager then there will almost certainly be issues. 

None of these problems are insurmountable, but I can't help thinking that it would be better to just avoid them completely.

4) Redefine @SessionScoped to be scoped to the web socket connection. 

I think this will just cause problems down the road. In particular, what would this mean in an on open method? The HTTP session or the web socket session.



Something else we should clarify is that these scopes should be usable from both annotated and programatic (i.e. MessageHandler) code.  

Stuart



----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine at sabot-durand.net>
> To: cdi-dev at lists.jboss.org
> Cc: "Stuart Douglas" <sdouglas at redhat.com>
> Sent: Monday, 25 November, 2013 11:13:28 AM
> Subject: Today's meeting agenda
> 
> Hi all,
> 
> Here are the points I’d like to discuss in our meeting today :
> 
> 1) Back on Websocket + RequestScoped issue : CDI-370 : Expand @RequestScoped
> and @SessionScoped to account for WebSocket
> Stuart Douglas will be our Guest Star to help us sort out if we can fix this
> issue on CDI side and if yes, if it’s doable in the MR timeframe
> 
> 2) If there’s time left let’s discuss the following point :
> 
> - CDI-406 Make stereotypes bean defining annotations
>     Should we define all stereotype as a bean definition annotation or should
>     clarify the fact that it’s not the case in the spec ?
> 
> - CDI-404 adding bean-defining annotations for Interceptor while setting
> bean-discovery-mode=« annotated »
> 
> - CDI-389 Revert CDI-85 (an easy one)
> 
> - CDI-397 Clarify Section 6.6.3 regarding singletons
>   An ambiguity, we all agree to clarify. I’d had we should check for all
>   singleton occurrence in the spec (they seems all related to EJB) and
>   perhaps think for a mention about singleton scope
> 
> - CDI-395 Public fields in extensions should not be allowed (also easy to
> decide)
> 
> I you’d like to have other issues put in priority please tell me. I took
> those to have a mix sample…
> 
> Antoine
> 
>  
>  
>