On 12-07-12 10:15 PM, Joe Walnes wrote:
>
>
> On Thu, Jul 12, 2012 at 6:22 PM, Danny Coward <danny.coward_at_oracle.com
> <mailto: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
> }
> }
> }
+1 for that => I do see this pattern used a lot with Atmosphere and
early adopter of WebSocket/Servlet [1]. Currently applications share
data using the original session created during the handshake, and that
seems to works pretty well.
-- Jeanfrancois
[1]
http://github.com/Atmosphere/atmosphere
>
>
>
>
>> ** 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
>