From: Pete Muir <pmuir@bleepbleep.org.uk>
To: "cdi-dev@lists.jboss.org" <cdi-dev@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@oracle.com>
Subject: [jsr342-experts] request scope for Web Sockets?
Date: 16 May 2013 19:21:40 BST
To: jsr342-experts@javaee-spec.java.net
Cc: Joseph Snyder <J.J.SNYDER@oracle.com>, Danny Coward
<danny.coward@oracle.com>, Rajiv Mordani <Rajiv.Mordani@oracle.com>,
"CHAN,SHING WAI" <shing.wai.chan@oracle.com>
Reply-To: jsr342-experts@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev