Dear all,
In my code that I have demonstrated at JDC, I made the routing logic based on message length, in each message decoder method willDecode, and the container succeed to route. Also I have used this for filtering unwanted payloads.
For me the willDecode method is a great filter without implementing any additional filter for message processing.
Cheers
Mohamed Taman
Sent from my iPhone
On Mar 22, 2013, at 1:44 AM, Danny Coward <danny.coward_at_oracle.com> wrote:
> On 3/21/13 4:18 PM, Noah White wrote:
>> 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.
> Yes I agree !
>>
>> 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.
> Without getting into the detail of it, JAX-RS messages come with a lot more metadata in the Http Headers that describe the message payload. Its that kind of information that we lack in the websocket message. All we really have when a message hits the websocket container is the message type: binary, text or pong. There's nothing much standard to build a multiplexing scheme on like there is in Http or restful webservices.
>
>>
>> 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?
> We absolutely could define our own metadata to describe messages. The subprotocol attribute of the handshake might serve as a useful place to attach this kind of message description/meta data, or some JSR356 specific headers in the handshake. Of course, the other issue for websocket is that the other end of the communication is often a piece of javascript, so it would need to participate in some way in such a scheme.
>
> These are all things we'll likely look at in the next version.
>
> - Danny
>
>>
>> -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
>
>
> --
> Danny Coward
> Java EE
> Oracle Corporation