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
> <mailto: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
>>>> <mailto: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
>>>>
>>>> “*/I/*/mprove your /*/Life/*/through *Science* and /*/Art/*/…”/
>>>>
>>>> Mohamed Mahmoud Taman
>>>>
>>>> /Business//Solutions,/
>>>>
>>>> /Systems Architect & Design Supervisor/
>>>>
>>>> /Java Team Leader/
>>>>
>>>>
>>>>
>>>> | JCP (Java Community Process) Member
>>>> <http://jcp.org/en/participation/members/T>
>>>>
>>>> |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.***
>>>>
>>>
>>
>>
>> --
>> <http://www.oracle.com> *Danny Coward *
>> Java EE
>> Oracle Corporation
>>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation