From: Werner Keil <werner.keil_at_gmail.com>
Date: Wed, 22 May 2013 12:45:59 +0200

Isn't at least WebSockets also adopted by BeJUG a lot?[?]
Why not try to get those guys involved if they have enough ideas, time and
experience to help out here?[?]

On Wed, May 22, 2013 at 12:18 PM, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:

> Regardless of what approach is decided on, as CDI spec lead I would prefer
> that this should be done in WebSockets, not CDI. This follows the precedent
> that we made with @TransactionScoped - that any additional contexts should
> be defined in the spec that "own" them, not in CDI. IMO this is a good
> thing, as the hard part of designing a context is understanding when it is
> active, and how it propagates, not understanding how to implement it. The
> experts in technology have a much better understanding of how it should
> propagate than the CDI EG does. As usual, of course, the CDI EG is happy to
> help any other group with the details and explain how contexts work.
>
> On 16 May 2013, at 19:21, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> > 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.
>
>