Hi folks,
I will get to some of the issues on the users list tomorrow, but in the
meantime, here's the pot pourri I'd like to put in v013 at the end of
this week.
* Please Rename: HandshakeRequest.getSession() ->
HandshakeRequest.getHttpSession()
I think this is a no brainer ! yes unless I hear otherwise.
* Reshape of async send Future
I send this a while back, Justin had some concerns which I think I
answered, but I'm putting it out there again one last time in case there
are other issues:
http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-02/message/20
* Remove Session.getId()
Mark raised this - what is it for, should we remove it ? Obviously it
doesn't have the same use outside the web container that the HttpSession
ID does in the servlet API, but think its useful that websocket Session
objects have a unique id that outlives the object itself for
logging/tracking/debugging purposes. So I think we should keep it in.
* Add new SessionException for container generated errors during the
lifetime of an endpoint
This has not been filed in JIRA (yet!), but it came from Pavel on our
implementation team. During the lifetime of our endpoints, there are
three kinds of error that can arise during operation:-
1) Decode/Encode exceptions
2) any developer exception thrown out the top of annotated methods
3) container generated exceptions (network errors, send error on
@WebSocketMessage return)
In particular, it would be helpful in the @WebSocketError method to
easily be able to distinguish between the three types. So the proposal
is to add a typed exception SessionException that the container can use
for category 3). Its data would be
- a wrapped cause
- the session
as well as a descriptive message.
I think it's useful - any other opinions on this one ?
* Consider merging Session and RemoteEndpoint into one interface
The reason this came up is that there is one RemoteEndpoint per Session,
so they could be merged without loss of functionality. However, on a
conceptual level I think that logically the remote peer and the
connection are fundamentally different (and maybe we will have in future
specs other 'views' onto the remote peer in addition to RemoteEndpoint).
On a practical level, if we merged them, the API would get too big. So
I'd like to keep this API as it is unless I hear strong support to merge
the interfaces into one.
That's it for now,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation