jsr356-experts@websocket-spec.java.net

[jsr356-experts] Simplified MessageHandler configurations

From: Danny Coward <danny.coward_at_oracle.com>
Date: Wed, 21 Nov 2012 17:47:32 -0800

Hi folks,

I tried to come up with a simple scheme for message handling where
multiple message handlers per native websocket message type were
allowed....and have concluded there isn't a clean way for it to work. I
thought that using the order of the message handlers configured on the
session would be enough, but since the stream decoders only get one shot
at decoding the message, that won't work. For POJOs with multiple
@WebSocketMessage methods handling the same native message
type...there's just not enough information in the web socket messages to
make it work, no content qualifier, no mime-type.

So we'll follow the simpler scheme (see below) that Scott and Justin
were advocating.

I still think my use case of having the container do some multiplexing
like this:-

@WebSocketMessage
public void login(LoginMessage lm)

@WebSocketMessage
public void chat(ChatMessage chat)

@WebSocketMessage
public void randomMessage(String message)

in one single POJO is really useful, but not one we will be able to
support in this release. Perhaps in the next release, if developers want
some kind of multiplexing based on MessageHandlers, then we could look
at defining a formal scheme - perhaps we can use the subprotocol and a
Policy class to support the multiplexing. But, that's for the next version.

So for now, here's the simpler model: restrict the model to being able
to configure only one MessageHandler per native websocket message type:
text, binary and Pong.

So the registration methods will need to throw exceptions if the
developer tries to configure more than one MessageHandlers for a native
websocket message type. POJOs that declare more than one method to
handle messages of a given native type will be defined as non-valid.

So, for example

@WebSocketEndpoint("/hi")
public class Hello {
     @WebSocketMessage
     public void sayIt(String message) {
     }

     @WebSocketMessage
     public void sayItAgain(Reader r) {
     }
}

will not be valid, nor will

@WebSocketEndpoint(
     "/hi",
     decoders={AppleTextDecoder.class}
     )
public class Hello {
     @WebSocketMessage
     public void sayIt(String message) {
     }

     @WebSocketMessage
     public void eatIt(Apple a) {
     }
}

Not for this version anyway !

But

@WebSocketEndpoint("/hi")
public class Hello {
     @WebSocketMessage
     public void sayIt(String message) {
     }

     @WebSocketMessage
     public void consumeData(ByteBuffer bb) {
     }
}

will be.

- Danny

-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation