Hi folks,
Some of you will remember our discussion, initiated by Scott I think,
that led us to limit the number of MessageHandlers that can be
registered on a Session to one per native websocket message type: text,
binary, pong.
The basic reason was that the incoming message only has that level of
information to tell the container which handler to look for. Trying to
determine which of multiple handlers per native websocket message type
is not possible since there is just not enough information on the message.
But, there is a potential relaxation of that rule that may be useful in
some circumstances, which is to allow one *.Basic and one *.Async
handler for text, and the same for binary. The container makes some
decision as to whether it wants to deliver a message as a whole message
or in parts (and as a reminder, this may or may not directly map onto
the frames in which the messge is coming).
So, for example, if the container had decided it could deliver a given
text message in parts, it could deliver it to the *.Async handler. If it
decided it couldn't, it would deliver to the *.Basic handler. If there
was only an *.Async handler, it would always call that. If there was
only a .Basic handler it would always call that for that native message
type.
The same relaxation would follow for the annotations.
So that
@WebSocketMessage
public void handleAll(String s) {..}
@WebSocketMessage
public void handleBits(String part, boolean last) {..}
would be allowed, where today it is not.
My own take on this is that:
I think it does work :)
It makes the restriction on the # MessageHandlers harder to explain :(
It could be useful in some circumstances, but not many :|
What are other folks opinions ?
Can anyone think of a compelling usecase to justify the increase in
complexity to explain this ? Or should we just wait until the next
version when we can look at some more formal way to allow multiple
message handlers.
Thanks,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation