Re: [cdi-dev] Today's meeting agenda

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

> > 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(a)sabot-durand.net&gt; >>> To: cdi-dev(a)lists.jboss.org >>> Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt; >>> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >>