Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: joakimerdfelt
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

Use of Session (add|remove|get)MessageHandler from annotated endpoint

Created: 18/Apr/13 10:05 PM   Updated: 18/Apr/13 10:44 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Participants: gregwilkins and joakimerdfelt

 Description  « Hide

As reported on jsr356-experts:

If you have an annotated endpoint via @ClientEndpoint or @ServerEndpoint, can you use the various Session MessageHandler calls?


This would seem to makes sense, but the rules for replacing a "native websocket message type" should still apply, right?
So that if we have a @OnMessage annotated method with a TEXT type (such as String) then Session.addMessageHandler(MessageHandler.Whole<String>) shouldn't work.


Should we be able to remove a @OnMessage annotated method?
Perhaps by exposing these annotated methods a implementation specific MessageHandlers?


Should this also list the annotated @OnMessage methods as MessageHandlers?

It could be argued that it is confusing to have Session.addMessageHandler() fail with a reason that the the native websocket message type is already in use, but not have the means to remove the active one via removeMessageHandler(), or have the means to list them via getMessageHandlers().

This is another area needing clarification in the spec.

A proposal is to have to have the following methods not be available for Annotated WebSocket Endpoints.


Throwing IllegalStateException when attempting to use them.

gregwilkins added a comment - 18/Apr/13 10:44 PM

Is there really a need to allow ongoing add/remove of message handlers?

I would think that it is sufficient to have only add and to allow it only during a call to onOpen. After that, the handlers should be fixed and thus it does not matter if they are annotated or otherwise.

In cometd, we had a lot of problems with this kind of race - when we would notify an application of a new channel subscription which would often result in new message handlers being registered. If this is not made atomic, then it is always possible for messages to arrive before the message handler is registered. The solution in cometd was to have the mutable methods (eg addMessageHandler) only on a version of the interface that is only passed to the equivalent of onOpen.