websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-192

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

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      As reported on jsr356-experts:
      http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-04/message/5

      (snip)
      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().
      (/snip)

      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.

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

      Throwing IllegalStateException when attempting to use them.

        Activity

        Hide
        gregwilkins added a comment -

        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.

        Show
        gregwilkins added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            joakimerdfelt
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: