Skip to main content

[jsr356-experts] MessageHandler options: was Re: Call precedence of multiple MessageHandlers

  • From: Danny Coward < >
  • To:
  • Cc:
  • Subject: [jsr356-experts] MessageHandler options: was Re: Call precedence of multiple MessageHandlers
  • Date: Fri, 09 Nov 2012 17:08:55 -0800

Thanks Scott. I'm going to think on this some more. But just to try to contrast the two approaches so as to solicit more feedback, in case we are missing something here:-

The two handlers policy:-
- max two handlers per connection, one for text based messages, one for binary.
- call policy: ask the text handler to handle text messages, ask the binary handler to handle binary messages
- unhandled messages: unhandled messages always cause an onError call.
- consequently, a maximum of two @WebSocketMessage annotated methods per @WebSocketEndpoint class, maximum one with String capable arguments, maximum one with binary capable arguments
- developer modeling messages with multiple classes does own multiplexing and downcasting - if (message instanceof Apple) {} else if { } etc.


The many handlers policy:-
- many handlers per connection
- call policy: the first handler that can handle the message consumes it.
- same policy of unhandled messages: unhandled messages always cause an onError call.
- maximum of one @WebSocketMessage annotated methods with the same message argument type per @WebSocketEndpoint class.
- developer modeling messages with multiple classes has container do the multiplexing

Other opinions ?

- Danny



On 11/7/12 6:53 PM, Scott Ferguson wrote:
" type="cite">
On 11/7/12 5:58 PM, Danny Coward wrote:
" type="cite"> Hi Scott, all,

" type="cite">
" type="cite">

Yes. That's what I was thinking.
OK I see. I definitely like the simplicity much better than my original writeup, but it does a little restrictive to limit the developer to one/two handlers.

There's a different approach to consider that might be even simpler...

- Allow multiple MessageHandlers to be registered in an (ordered) list. When a message comes in, just pick the first MessageHandler in the list that is able to handle the message, and stop.

...yet retain the flexibility to handle different types of messages with different handlers, for those that want to.


I think Justin put it well:

"I can't imagine too many cases where someone will need multiple encoders/decoders but those people are free to implement an aggregating encoder/decoder and compose their needs into "one."

An application could use a single composite decoder to implement that chaining model, if it's appropriate.

But it's not a design that's well-suited to general decoding (for example java.io.Serialization):

A better suited model would be:

  @WebSocketMessage
  public void onMessage(Message msg) {
    msg.doStuff();
  }

Where the decoder will instantiate/create

  class ChatMessage implements Message or
  class LogoutMessage implements Message

as determined by the websocket message. You could use java.io.Serialization with the second model, but not the chaining model.

You can see the problem with chaining in the current javax.net.websocket.Decoder.BinaryStream, which cannot support the chaining model at all. In the case where it could be supported, the Decoder.Text, the willDecode(String) is clunky. And that model is essentially impossible for encodings like java.io.Serialization.

So the chaining model is pretty specific for a certain kind of application. Too specific, I think, to be in this layer.
" type="cite"> Separately, Scott I logged your suggestion earlier in the thread to move the registration of decoders 'closer' to the MessageHandlers - I agree doing so will make the case of having a MessageHandler.DecodedObject<T> without a Decoder for objects of type T less common.

thanks!

-- Scott

" type="cite">
- Danny









" type="cite">
In practice, I'd expect most sub-protocols would be either text or binary but not both. (Not enforced, of course.)



" type="cite">
-- Scott



--
Danny Coward
Java EE
Oracle Corporation



--
Danny Coward
Java EE
Oracle Corporation


[jsr356-experts] Call precedence of multiple MessageHandlers

Danny Coward 11/02/2012

[jsr356-experts] Re: [jsr356-users] Call precedence of multiple MessageHandlers

Scott Ferguson 11/03/2012

[jsr356-experts] Re: [jsr356-users] Call precedence of multiple MessageHandlers

Mark Thomas 11/03/2012

[jsr356-experts] Re: [jsr356-users] Call precedence of multiple MessageHandlers

Justin Lee 11/05/2012

[jsr356-experts] Re: [jsr356-users] Re: Call precedence of multiple MessageHandlers

Danny Coward 11/06/2012

[jsr356-experts] Re: [jsr356-users] Re: Call precedence of multiple MessageHandlers

Scott Ferguson 11/07/2012

[jsr356-experts] Re: Call precedence of multiple MessageHandlers

Danny Coward 11/08/2012

[jsr356-experts] Re: Call precedence of multiple MessageHandlers

Scott Ferguson 11/08/2012

[jsr356-experts] MessageHandler options: was Re: Call precedence of multiple MessageHandlers

Danny Coward 11/10/2012
 
 
Close
loading
Please Confirm
Close