[cdi-dev] Fwd: [jsr342-experts] request scope for Web Sockets?
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:
> A user can easily use CDI in WebSocket apps already via DeltaSpike ContextControl. Even if the container does not yet support it.
> ----- Original Message -----
>> From: Pete Muir <pmuir at bleepbleep.org.uk>
>> To: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>> 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
>>> 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:
>>> 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
>>> requirement that would require a new revision of the spec(s). Since this
>>> involves the interaction of three specs, I'm starting the conversation
>>> 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
>>>> The request scope is active:
>>>> - during the service() method of any servlet in the web
>>>> application, during the doFilter() method of any servlet filter
>>>> when the container calls any ServletRequestListener or
>>>> - 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
>>>> timeout method and during message delivery to any EJB
>>>> 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
>>>> 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
>>> "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
>>> 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
>>> 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
>>> define a "message" scope or something similar to cover individual
>> Web Socket
>>> Let us know what you think.
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
|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...
More information about the cdi-dev