On Thu, Jul 12, 2012 at 6:22 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> 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.
>
Let's say a user creates a decorator for the MessageListener interface
(simple example: to count throughput of messages). It would be pretty easy
for them to wrap an existing MessageListener when calling
Session.addEventListener().
Sounds good so far. I think as long as we offer nice OO style APIs, it
gives users the power to do things like this.
However, once we start introducing things like annotations, it adds
complexity as there are no clear points to alter the behavior (or maybe
there are - I'm just not seeing them). Just something to keep in mind if we
continue down the annotation route.
> ** 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 ?
>
I mean, having the ability for a single URL to be respond to both HTTP
requests and WebSocket requests.
For example:
@WebServlet(urlPatterns={"/blah"}
class MyServlet {
void doGet(...) {
if ("websocket".equals(req.getHeader("Upgrade")) {
req.upgrade(...); // websockety stuff
} else {
// standard GET request
}
}
}
> ** 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.
>
Looks good.
-Joe