[cdi-dev] Today's meeting agenda

[Stuart Douglas]

> 
> 
> > However, I believe "@WebSocketConnectionScoped" should be defined in the
> > WebSocket spec.

I agree, this definition does not belong in the CDI spec.

Stuart

> 
> > 
> > Martin
> > 
> > Dne 25.11.2013 12:03, Stuart Douglas napsal(a):
> >> 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
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >> 
> 
>