Thanks Joe and welcome out of JCP process limbo! Thanks for the detailed
review and comments.
See comments inline....I snipped out some that I'm going to cover in the
summary in the next few emails:
>
> ** Cross cutting concerns*
> It wasn't clear whether javax.servlet.Filters would intercept the
> WebSocket. In some of the apps there are cross-cutting interceptors
> that perform functions such as: authentication/authorization, auditing
> (recording all messages across all endpoints for compliance reasons),
> monitoring (timings, throughput, latency, etc), and session tracking
> (who's currently connected).
I think that's up to the implementation at this point. I'd expect
implementations built on the servlet api would intercept the Http
handshake with any filters configured to that URI, but I'm not sure we
need to say anything about that in this JSR.
>
> ** Upgrading HTTP requests*
> Not clear how URL endpoints could be defined that can handle both
> vanilla HTTP requests (i.e. a Servlet) and WebSockets, depending on
> whether an upgrade was requested.
I think the scope for us is to define components that can participate in
the initial websocket handshake (for example check URLs, subprotocols,
extensions) and thereafter deal (only) with web socket messages. I
hadn't envisioned that these components would try to handle general Http
requests too. Via access to the HttpSession, I'd expect web socket
components to be able to share data with servlets and JSPs in the same
web application. Is that the kind of use case you had in mind ?
>
> ** Non-blocking closes*
> While there are non-blocking versions of the send() methods, there is
> no way to do a non-blocking close().
At the moment we haven't said anything about what exiting the close
method is supposed to have done - whether it waits until the socket is
closed, or whether it issues the request to close it to the
implementation and moves. The latter approach might be a reasonable way
to do since we could use the endpoint.hasClosed(session) call to notify.
>
> ---- Minor API questions/suggestions/opinons ----
>
> *Endpoint.hasXXX()*: More of a stylistic thing, but elsewhere the
> onXXX convention is used - can we be consistent?
>
> *Endpoint.handleError()*: This seems a bit generic. At the very least,
> we should be explicit on whether this is for handling uncaught
> exception in user code (MessageListeners), or network related problems
> - which require very different treatment depending on the nature of
> the application.
>
> *Endpoint.handleError()*: Should this be able to handle Throwable (not
> just Exception)?
>
> *Session.addEncode()/Session.addMessageListener()*: Should we also
> supply equivalent remove methods? An example case for this is when an
> initial listener needs to replace itself with a more appropriate
> listener once it learns more about the client.
>
> *Session.setMaximumMessageSize()/Session.setTimeout()*: What are the
> defaults if these are not set (container specific)? Does the user have
> the facility to set inifinite values (i.e. never timeout)?
>
> *Session.isActive()/Session.isSecure()*: Danny, I think you messed up
> the source code here... isSecure() does not appear in the JavaDoc, and
> isActive() contains a bit of isSecure().
>
> *Session.getHttpSession()*: HttpSessions are typically considered
> server side things - this makes little sense for a WebSocket client.
> Although we want to maintain as much API consistency as possible
> between server and client, we also need to cater for things that don't
> make sense in a both contexts.
>
> *Session*: I can't imagine doing anything useful without the
> HttpRequest (allowing users to get things like user Principal, request
> parameters, HTTP headers, cookies, remote host, etc). At the same time
> I see the argument against (especially in a client, or non Servlety
> deployment). Maybe there should be sub-interfaces that provide more
> environment specific capabilities (e.g. ClientSession, ServerSession).
>
> *Session*: Vocabulary thing... Session is such an overloaded term in
> the JEE space. How about something with a more meaningful description,
> like Connection?
>
> *RemoteEndpoint*: If the user is not using a custom encoder, what
> would type <T> be? Would they have to pass RemoteEndpoint<Void> around
> their code?
>
> *EncodeException/DecodeException*: Given that encoding is an IO
> related activity, should this extend IOException?
>
> *ServerConfiguration.checkOrigin()/getPreferredSubprotocol()*: It
> wasn't clear how to change the behavior here. Is ServerConfiguration
> meant to be subclassed? This seems a little messy as it inherits
> members which are clearly not meant to be overriden (e.g. getURI()).
>
> *MessageListener*: This would be cleaner if it was generified with a
> void onMessage(T data) method, as opposed to an empty interface. It
> will avoid instanceof checks and casting elsewhere in infrastructure
> and cross-cutting services (e.g. generic MessageListener decorators).
> Ditto for Encode/Decoder.
>
> *MessageListener.onMessage()*: It would be convenient if this also
> provided a Session parameter, so a single MessageListener instance
> could be used to handle multiple connections.
>
> *Close.Code.TLS__HANDSHAKE_FAILURE*: Why the double underscore?
Thanks for the careful review - let me address these in v003.
>
>
> ** Annotations*
> I have no objection to the annotations, but at the same time, I'm not
> seeing how they make things better. Could someone please clarify?
>
There was a big push in EE 6 to use annotations as a way to make
creating and deploying all sorts of components easier. I suppose the
central idea is to be able to take a POJO with few restrictions on
naming or other potentially complicated API design restrictions together
with a few annotations and be able to easily create an EJB or a web
service endpoint or a servlet without needing a deployment descriptor. I
know opinions vary on the success of this kind of approach, but we are
scoped to see if we can emulate that kind of approach with web sockets.
JAX-RS is a useful parallel.
- Danny
>
>
> cheers
> -Joe
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation