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

[Pete Muir]

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.