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

[Mark Struberg]

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
>