Just a bit of process background...
The JCP defines the MR process. We use the MR process for two purposes:
1. To update the spec document with "errata" that do not change the meaning
or requirements of the spec, but merely clarify or correct errors in the
spec. Generally, no RI or TCK change is required.
2. To update the APIs and/or requirements defined by the spec, creating a
new version of the spec. Such changes must generally be small and well
understood, not requiring extensive expert group discussion. Generally,
the RI and TCK will be updated.
If there was a clear consensus that this issue should be dealt with as an
errata, we would do #1.
At this point it's clear there is no consensus that this should be dealt
with as an errata, so #1 is out.
We'll continue the discussion and based on the results either do #2 to
some spec(s), or we'll defer the work to the next full JSR(s) of some spec(s).
In the mean time, the only safe conclusion is that this behavior is
"unspecified", and thus portable programs will not rely on the presence or
absence of a request scope for Web Sockets or other Servlet protocol handlers.
Kevin Sutter wrote on 05/21/13 14:06:
> We've been discussing this issue among the EG members here (java ee, cdi, and
> web sockets) and the consensus is that more thought needs to go into the "final
> solution". So, whether that's an MR or wait for the next Java EE 8, but the
> overall issue needs more investigation before deciding on a direction.
>
> But, what to do in the mean time? Bill's suggested errata update almost sounds
> too open-ended. But, it's my understanding from reading the JIRA that leaving
> it as is until Java EE 8 would prevent some scenarios from working as expected.
>
> Instead of providing a band-aid fix via an errata, I would propose an MR. Of
> course, the next question is whether we do an MR on the Java EE 7 platform, or
> the individual CDI and Web Socket specs... Regardless, I prefer the MR approach
> to allow for a more thorough discussion.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> Kevin Sutter, Java EE and Java Persistence API (JPA) architect
> mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
> http://webspherepersistence.blogspot.com/
> phone: tl-553-3620 (office), 507-253-3620 (office)
> http://openjpa.apache.org/
>
>
>
>
> From: Werner Keil <werner.keil_at_gmail.com>
> To: jsr342-experts_at_javaee-spec.java.net,
> Date: 05/21/2013 02:05 AM
> Subject: [jsr342-experts] Re: [javaee-spec users] request scope for Web
> Sockets?
> --------------------------------------------------------------------------------
>
>
>
> All,
>
> Given EE 8 shall also benefit from a more unified approach to state thanks to
> JSR 350, dealing with scope in a more unified way as Markus suggested looks like
> a good thing, too. Either on the umbrella level or in a separate cross-cut JSR
> like CDI or State Management where better dealt there.
>
> Whatever causes less disruption, errata or a MR should be done for now.
> Although the umbrella JSR is approved and final, it's not like products spread
> like mushrooms, especially in the EE space. Some are just jumping the Java EE 6
> bandwagon with their products:-D
>
> Werner
>
> Am 17.05.2013 11:52 schrieb "Markus Eisele" <_myfear_at_web.de_
> <mailto: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.
>