if the app server handed off traffic to either the servlet or the websocket
container based on that upgrade header, both containers would be free to
map URLs independently of one another with neither knowledge nor
conflicts. It does require more smarts in the appserver and the ability to
register various handlers for different kinds of traffic, though. In
GlassFish, that's not so hard because grizzly is already taking care of
such details. I'm not sure how that'd work in tomcat/jetty based systems,
though.
On Thu, Jul 12, 2012 at 10:33 PM, Joe Walnes <joe_at_walnes.com> wrote:
> Another option would be to allow the container to have both servlet and
> websocket handlers mapped to the same URL, and the container would choose
> the appropriate one based on the Upgrade header.
>
> On Thu, Jul 12, 2012 at 9:24 PM, Justin Lee <jlee_at_antwerkz.com> wrote:
>
>> 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
>>
>>
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/twitter http://antwerkz.com/github