users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re: Use of Session (add|remove|get)MessageHandler from annotated endpoint.

From: Joakim Erdfelt <joakim_at_intalio.com>
Date: Wed, 10 Apr 2013 09:46:05 -0700

I like the idea of disabling the following when working with annotated
websockets.

Session.addMessageHandler()
Session.getMessageHandlers()
Session.removeMessageHandlers()

I would think throwing a IllegalStateException when attempting to be used
is appropriate.


--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org
On Tue, Apr 9, 2013 at 7:17 PM, Mark Thomas <mark_at_homeinbox.net> wrote:
> On 03/04/2013 14:24, Joakim Erdfelt wrote:
>
>> If you have an annotated endpoint via @ClientEndpoint or
>> @ServerEndpoint, can you use the various Session MessageHandler calls?
>>
>> Session.addMessageHandler()
>>
>>    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.
>>
>> Session.removeMessageHandler()
>>
>>    Should we be able to remove a @OnMessage annotated method?
>>    Perhaps by exposing these annotated methods a implementation specific
>> MessageHandlers?
>>
>> Session.getMessageHandlers()
>>
>>    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().
>>
>
> or just not allow any of the Session MessageHandler calls in this case.
>
> I have no strong views on this either way.
>
> Mark
>
>