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 <joe_at_walnes.com> wrote:
>
>
> 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
>
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/twitter http://antwerkz.com/github