Skip to main content

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

  • From: Justin Lee < >
  • To:
  • Subject: [jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code
  • Date: Thu, 12 Jul 2012 22:24:38 -0400

Personally, i think implementations should never let a request with an upgrade hit a servlet.  A case could be made for Filters but once they're off into servlets, things get wonky really quickly.  And I haven't seen anything I like coming out of the servlet group for those cases.

On Thu, Jul 12, 2012 at 10:15 PM, Joe Walnes < " target="_blank"> > wrote:


On Thu, Jul 12, 2012 at 6:22 PM, Danny Coward < " target="_blank"> > 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




--



[jsr356-experts] Re: [jsr356-users] For Review: v002 API and example code

Joe Walnes 07/10/2012

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Danny Coward 07/12/2012

Message not available

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Joe Walnes 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Justin Lee 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Joe Walnes 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Justin Lee 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Jeanfrancois Arcand 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: For Review: v002 API and example code

Greg Wilkins 07/13/2012
 
 
Close
loading
Please Confirm
Close