Re: [cdi-dev] Fwd: [jsr342-experts] request scope for Web Sockets?

Hi! A user can easily use CDI in WebSocket apps already via DeltaSpike ContextControl. Even if the container does not yet support it. LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)bleepbleep.org.uk&gt; > To: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > Cc: > Sent: Wednesday, 22 May 2013, 12:15 > Subject: [cdi-dev] Fwd: [jsr342-experts] request scope for Web Sockets? > > All, please see below, and let me know your thoughts. > > I would prefer to see the Web Sockets spec handle this, just like we had JTA > handle the TransactionScoped context details. > > Begin forwarded message: > >> From: Bill Shannon <bill.shannon(a)oracle.com&gt; >> Subject: [jsr342-experts] request scope for Web Sockets? >> Date: 16 May 2013 19:21:40 BST >> To: jsr342-experts(a)javaee-spec.java.net >> Cc: Joseph Snyder <J.J.SNYDER(a)oracle.com&gt;, Danny Coward > <danny.coward(a)oracle.com&gt;, Rajiv Mordani <Rajiv.Mordani(a)oracle.com&gt;, > "CHAN,SHING WAI" <shing.wai.chan(a)oracle.com&gt; >> Reply-To: jsr342-experts(a)javaee-spec.java.net >> >> Experts, >> >> An issue has come up about the definition of the CDI request scope and how >> it applies to Web Sockets applications. The issue is reported here: >> https://issues.jboss.org/browse/CDI-370 >> >> We're trying to decide whether this is a simple oversight that could be >> corrected with an errata to the existing spec(s), or whether it's a > missing >> requirement that would require a new revision of the spec(s). Since this >> involves the interaction of three specs, I'm starting the conversation > here. >> Danny, Pete, Shing Wai, please forward this message to your expert groups >> for their input as well. >> >> >> Here's the definition of when a request scope is active and when it is > destroyed: >>> The request scope is active: >>> >>> - during the service() method of any servlet in the web >>> application, during the doFilter() method of any servlet filter > and >>> when the container calls any ServletRequestListener or > AsyncListener, >>> - during any Java EE web service invocation, >>> - during any remote method invocation of any EJB, during any >>> asynchronous method invocation of any EJB, during any call to an > EJB >>> timeout method and during message delivery to any EJB > message-driven >>> bean, and >>> - during any message delivery to a MessageListener for a JMS >>> topic or queue obtained from the Java EE component environment. >>> >>> The request context is destroyed: >>> >>> - at the end of the servlet request, after the service() method, all >>> doFilter() methods, and all requestDestroyed() and onComplete() >>> notifications return, >>> - after the web service invocation completes, >>> - after the EJB remote method invocation, asynchronous method > invocation, >>> timeout or message delivery completes, or >>> - after the message delivery to the MessageListener completes. >> It would be easy to "fix" the first bullet in each list above by > saying >> "oops, we forgot to include the work done by a protocol handler in >> Servlet 3.1". Since all this other work done by Servlet applications >> is part of the same request scope, adding the work done by protocol >> handlers would make sense. >> >> But, we have to decide if that's the fix we want. >> >> Adding bullet items to each list to cover specific Web Socket operations >> might be more what people are expecting, resulting in a request scope for >> Web Sockets that's "smaller" than the request scope for the > corresponding >> http request. Even if we did that, we would still need to define clearly >> whether or not a request scope is active during any arbitrary protocol >> handler operation (not just Web Socket protocol handlers). Defining it >> for Web Sockets but not defining it for protocol handlers in general might >> be acceptable. Defining it one way for Web Sockets and a different way >> for other protocol handlers would not be acceptable. >> >> >> Should we fix this as an errata by saying that obviously protocol handler >> operations should've been included in those lists of Servlet > operations? >> Or should we add items to each list to cover specifically Web Socket >> operations? (In which case what do we say about protocol handlers in >> general?) This would clearly require a new version of either the CDI >> spec or the Web Sockets spec. >> >> If we defined all Web Socket operations for a single http request to be >> part of the same request scope (the "errata" approach), we could > later >> define a "message" scope or something similar to cover individual > Web Socket >> operations. >> >> Let us know what you think. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev