Nigel,
I'm not sure how at this point this issue impacts the JMS EG. While there
may be similarities to how @OnMessage methods work compare to MDBs, the JMS
spec doesn't define MDBs and at best the JMS EG is interested in how JMS
based MDBs interact with contexts, which the WS EG should have raised as a
request to the EE EG.
I am however glad that the issue of missing contexts is being noted by the
EE EG, and how it's not a JMS issue any longer. Can the open issue be
closed at this point?
John
On Mon, May 20, 2013 at 10:04 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 07/05/2013 14:38, Nigel Deakin wrote:
>
>> On 07/05/2013 14:27, Nigel Deakin wrote:
>>
>>> https://java.net/jira/browse/**JMS_SPEC-121<https://java.net/jira/browse/JMS_SPEC-121>
>>> Injection of JMSContext objects not possible in a WebSocket @OnMessage
>>> or @OnClose callback method
>>>
>>> If you inject a {{JMSContext}} into a websocket {{ServerEndpoint}} you
>>> can use it in the {{_at_OnOpen}} callback, but if
>>> you attempt to use it from the {{_at_OnMessage}} or {_at_OnClose}} callbacks
>>> you get an exception from the CDI container
>>> because there is no valid request scope or transaction scope. From a
>>> user perspective it would seem reasonable to expect
>>> to be able to use an injected {{JMSContext}} in these places.
>>>
>>
>> JMS 2.0 defines an injected JMSContext to have transaction scope if there
>> is a current transaction, and request scope
>> otherwise. However neither scope is available in a websocket @OnMessage
>> or @OnClose callback.
>>
>> This seems to be an inconsistency in the CDI specification. Although
>> there is no valid HTTP request during the
>> @OnMessage and @OnClose callbacks, CDI already widens the definition of
>> @RequestScoped to cover cases which have no
>> relationship with HTTP. For example CDI 1.0 states that a MDB's onMessage
>> method is executed within a request scope,
>> even though there is no HTTP request involved. Now that WebSockets are
>> part of Java EE 7 (JSR 356), it seems a bit
>> arbitrary for a MDB callback to have a valid request scope, but for a
>> WebSocket callback to not be.
>>
>> I asked the CDI expert group to consider whether a future version of CDI
>> should extend the definition of @RequestScoped
>> to include a WebSocket @OnMessage callback. This is
>> https://issues.jboss.org/**browse/CDI-370<https://issues.jboss.org/browse/CDI-370>
>>
>
> This issue has now been picked up by the Java EE expert group. Joint spec
> lead Bill Shannon is considering whether it should be resolved as "an
> errata to the existing spec(s), or whether it's a missing requirement that
> would require a new revision of the spec(s)" (By "spec" he's referring to
> CDI and/or WebSockets, not JMS).
>
> Here's his email to the Java EE experts:
> https://java.net/projects/**javaee-spec/lists/jsr342-**
> experts/archive/2013-05/**message/0<https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-05/message/0>
>
> Bill's suggestion is that a WebSocket @OnMessage callback should have a
> valid request scope, where the lifecycle of the request lasts for the
> duration of the WebSocket endpoint. However he's asking for comments.
>
> My reaction is each WebSocket @OnMessage callback should constitute a
> separate request, just like a MDB message callback currently does. Defining
> that multiple @OnMessage callbacks occur in the same request doesn't seem
> right to me - this sounds closer to the definition of session scope than
> the definition of request scope.
>
> Discussions are continuing - I'll keep this group updated on progress. If
> you have a view please make it here (and I'll pass it on) or directly to
> the Java EE EG via the Java EE user alias.
>
> Nigel
>