Hi, all.
I also think 'errata' way is preferable for this release.
Regards,
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.