[jsr342-experts] Re: [javaee-spec users] request scope for Web Sockets?

From: Yoon Kyung Koo <kyungkoo_yoon_at_tmax.co.kr>
Date: Tue, 21 May 2013 11:49:03 +0900

Hi, all.

I also think 'errata' way is preferable for this release.

 Yoon Kyung Koo

 Software Innovation Driver
 Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
 PGP  http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
2013. 5. 17.,  6:52, Markus Eisele <myfear_at_web.de> ۼ:
> Hi Bill/All,
> I had to sleep over this and I'm still unhappy with my thoughts.
> The tight coupling to the request-response model is irritating with bidirectional protocols and I really think your idea of defining a MessageScope is needed to fix it generally.
> Reading the linked issue I feel the need to pull the scopes up to the umbrella spec to make sure they work equally in all contained specs..
> If we could agree to follow that approach in EE8 I would say it is ok to go the 'errata' way for this release. 
> Cheers,
> M
> Am Donnerstag, 16. Mai 2013 schrieb Bill Shannon :
> 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.