Add checked exceptions to ClientContainer.connect and ServerContainer.publish methods. about websocket HOT 7 CLOSED

• Issue Imported From: https://github.com/javaee/websocket-spec/issues/47
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek
• Original Issue Closed By:@glassfishrobot

from websocket.

@glassfishrobot Commented
Reported by dannycoward

from websocket.

@glassfishrobot Commented
dannycoward said:
Here's my current thinking, which we will discuss in the expert group.

MessageHandlers and Decoders

Principles

Each message is handled by at most one message handler
Messages that are unhandled result in calls to onError/@WebSocketError callbacks so developers always know if incoming messages are not handled
Developer provided decoders are chosen before platform decoders.
If a decoder fails, the error is delivered and no more decoders are attempted.

Process

1. a whole string message arrives

a) if there is an MessageHandler.AsyncText handler - do not call it
b) if there is an MessageHandler.CharStream handler - do not call it
c) if there is a MessageHandler.Text handler handler, call it and stop, using the first developer provided Decoder.TextStream or Decoder.Text, if any.
d) if there is a MessageHandler.DecodedObject
then try to find a Decoder.Text or a Decoder.TextStream. Look, in order, through developer provided ones (single list, may contain both Text and TextStream types). Then look through platform provided ones. Use the first match to decode it. If the decode works, call the MessageHandler and stop, if not, call the onError/@websocket method with the decode exception and stop. If no decoder is found, the message is unhandled.
Option: prefer higher level objects to lower level ones. i.e. if there is a decoder for T, and there is a MessageHandler.DecodedObject, and also a MessageHandler.Text, choose the MessageHandler.DecodedObject.

e) If the message is unhandled, call back on the onError/@WebSocketError method. We may need a new exception type for Unhandledmessages.

2. a whole binary message arrives: same process as 1).

3 the first piece of a chunked string message arrives.

a) if there is an MessageHandler.AsyncText handler - call it repeatedly until all the message has arrived and stop
b) if there is an MessageHandler.CharStream handler - call it with a Reader linked to the incoming parts, and stop
c) if there are MessageHandler.Text or MessageHandler.DecodedObject handlers, wait for all the string pieces to arrive, building the whole message as you go (subject to the buffer limit defined on the API). If the buffer limit is exceeded call the onError/@WebSocketError method on the endpoint. Otherwise, using the whole message, jump to the analogous steps for 1c), d) and e).

4. the first piece of a chinked binary message arrives

same process as 3) but for binary.

from websocket.

@glassfishrobot Commented
dannycoward said:
This has now been fixed.

from websocket.

@glassfishrobot Commented
Was assigned to dannycoward

from websocket.

@glassfishrobot Commented
This issue was imported from java.net JIRA WEBSOCKET_SPEC-47

from websocket.

@glassfishrobot Commented
Marked as fixed on Friday, November 2nd 2012, 5:34:16 pm

from websocket.