This has been opened as a spec clarification bug at
http://java.net/jira/browse/WEBSOCKET_SPEC-192
--
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 Wed, Apr 10, 2013 at 9:46 AM, Joakim Erdfelt <joakim_at_intalio.com> wrote:
> 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
>>
>>
>