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

Bruno Borges bruno.borges at oracle.com
Mon May 27 17:06:59 EDT 2013

The way I found to integrate WebSockets with other technologies, is by 
using CDI Events.

I've blogged about it here (integration between WS and JMS):

I've also played around with JAX-RS 2.0 (receiving @GET messages and 
sending to WS endpoints using CDI Events).

IMO, this is great and works fine, but does not remove the need for a 
@MessageScope or some other fix in the WS spec, or the CDI spec.

On 05/26/2013 05:24 AM, Mark Struberg wrote:
> 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 at bleepbleep.org.uk>
>> To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>> 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 at oracle.com>
>>>   Subject: [jsr342-experts] request scope for Web Sockets?
>>>   Date: 16 May 2013 19:21:40 BST
>>>   To: jsr342-experts at javaee-spec.java.net
>>>   Cc: Joseph Snyder <J.J.SNYDER at oracle.com>, Danny Coward
>> <danny.coward at oracle.com>, Rajiv Mordani <Rajiv.Mordani at oracle.com>,
>> "CHAN,SHING WAI" <shing.wai.chan at oracle.com>
>>>   Reply-To: jsr342-experts at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev


|Bruno Borges (twitter @brunoborges)
Principal Product Manager | Java WebLogic Coherence GlassFish
Oracle LAD PM Team        | Cloud Application Foundation
+55 11 5187 6514 (Work)   | +55 11 99564 9058 (Mobi)|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20130527/661bc2ae/attachment.html 

More information about the cdi-dev mailing list