Ricardo brings up a very good point. This change will greatly increase the complexity of your endpoint forcing you to merge application logic concerns just because they share a common message type. This feels like an anti-pattern.
JAX-RS/Jersey handles a similar use case rather cleanly with MediaType, QueryParam, FormParam etc. to choose which resource matches the incoming request for a given Path.
I will check out the threads you referenced but I was wondering if but was wondering if there was any thought given to using some sort of jsr356 specific metadata that could be used to help make these routing decisions?
-Noah
On Mar 21, 2013, at 6:07 PM, Danny Coward <danny.coward_at_oracle.com> wrote:
> The basic issue is that there isn't enough information in an incoming websocket message for the container to know where to route it if there are multiple methods where it may land.
>
> If a text message comes in and you have two methods for handling strings, which one do you send it to ?
>
> We tried at length to come up with a simple solution (there were complicated ones...), you can look back at the expert group email for more context (in particular, last November). We would like it to be easier to have multiple message decoders and so on.
>
> We will look at some kind of application message multiplexing in the next version.
>
> - Danny
>
> On 3/21/13 2:59 PM, Ricardo Cervera-Navarro wrote:
>> Hi Mohamed, all,
>>
>> The Javadoc (b81) for OnMessage says: "Each websocket endpoint may only have one message handling method for each of the native websocket message formats: text, binary and pong."
>>
>> I had an example with several decoders and message types for text messages. After this change, my example just became more complicated and less clean: it made it harder to have different Java types for different kinds of text messages, there is only one decoder but it is significantly more complex, and my Endpoint class now has more conditional clauses.
>>
>> Could somebody share with us some of the reasons for the change?
>>
>> Thanks,
>> --
>> Ricardo Cervera-Navarro
>> Technical Writer
>>
>> On 3/14/2013 5:02 AM, Mohamed Taman wrote:
>>> Hi Andy,
>>>
>>> It is allowed to have more than @OnMessage per Endpoint. as in my code demo in JDC and it works with the same Glassfish b80 and Tyrus_b13.
>>>
>>> here is the code of endpoint, the 2 messages are in red.
>>>
>>> [...]
>>>
>>> On Thu, Mar 14, 2013 at 1:26 PM, Andy Moncsek <amo.ahcp_at_gmail.com> wrote:
>>>> Hi,
>>>> I upgraded to glassfish b80 (tyrus 1.0-b13) today and realized that only one @OnMessage works per Endpoint?! Can you confirm this? I get a validation error from GF, so this seem to be a wanted behavior. Also in tyrus SVN I can find comments like this: "MessageHandler registration validity checking algorithm (also applicable for annotated case).". So what was the reason to do so? Do I really have to deal with generic messages to communicate with one endpoint?
>>>>
>>>> Thanks
>>>>
>>>> Andy
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Thanks & Best Regards
>>>
>>>
>>>
>>> “Improve your Life through Science and Art…”
>>>
>>> Mohamed Mahmoud Taman
>>>
>>> Business Solutions,
>>>
>>> Systems Architect & Design Supervisor
>>>
>>> Java Team Leader
>>>
>>> | JCP (Java Community Process) Member
>>>
>>> |Oracle Egypt Architects Club board member
>>>
>>> | JavaOne & EG-JDC Speaker
>>>
>>> | SCJP, SCWCD, OCP PL/SQL
>>>
>>>
>>>
>>> e-finance,BLDG17, Smart Village,
>>>
>>> KM 28 Cairo-Alex Desert Road,
>>>
>>> Ground Floor, Giza, Egypt
>>> Postal Code : 12577
>>>
>>> ( : +(202) 3827 1422
>>>
>>> (: +(202) 3827 1499
>>>
>>> (: +(202) 3827 1599
>>>
>>> È: +(201) 00531 8017
>>>
>>> P Before you print Think about Your ENVIRONMENTAL responsibility.
>>>
>
>
> --
> Danny Coward
> Java EE
> Oracle Corporation