Hi Rossen,
Thanks for the feedback !
On 1/16/13 4:03 AM, Rossen Stoyanchev wrote:
> Hi Danny,
>
> As previously discussed offline, I have some feedback on the current draft of the spec.
>
> Programmatic Deployment of Endpoints -- server endpoints are discovered by annotations or by type (via ServerEndpointConfiguration). Applications and frameworks will benefit from having a programmatic way to deploy endpoints. The ServerApplicationConfiguration mechanism is useful but an application may prefer to deploy endpoints directly rather than remove from a list of scanned ones. If the Servlet API can be used as an example, not having such option is similar to Servlets being discovered by type or annotations without the option to deploy them via web.xml or ServletContainerInitializer.
Yes, this was in earlier drafts, but we removed this when we added the
scanning/ApplicationConfiguration scheme. I agree this would be useful
for frameworks, though I'm a bit worried about all the different modes
people might end up wanting. Is a one-at-a-time blocking deployment call
sufficient do you think ?
Endpoint Instances -- it should be possible to deploy endpoint instances in addition to endpoint types. I believe this point was raised on the user list before. The Tyrus implementation provides it as an option, so obviously it's considered useful there. By comparison the ServletContext in Servlet 3.0 allows registration of Servlets and Filters by instance and by type.
Yes you are not the only person to ask for this, and thanks for the
reminder about the servlet model - always good to look across to other
component models.
Currently the websocket implementations create a new instance of the
websocket endpoint per client connection. This provides developers with
an easy, single threaded model to deal with (unlike servlets). So the
deploy-by-config class / endpoint class scheme works well for that.
If we define (in addition) deployment of single endpoint instances, then
I think implementations would need to interpret that as meaning 'use the
same endpoint instance to handle all events and messages from all
clients' which is quite a different model. It might be ok to have both
models, but that would be how deploy by class and deploy by instance
would be.
>
> WebSocket Server Paths -- section 6.4 requires the WebSocket URI space to be relative to a single root. If I understand correctly in Web containers, WebSocket implementations will install a Servlet (or Filter) to handle the upgrade process and all WebSocket URIs will be relative to the mapping of that Servlet?
The idea of 6.4 is that all URIs for websockets in the same web
application are rooted at the context root of the web application.
> This seems unnecessarily restrictive. An application may want more freedom in organizing its URI hierarchy according to functionality or to be fully self-contained under its own root (e.g. 3rd party service deployed as a Servlet exposing both REST and WebSocket services). I see the Tyrus implementation currently deploys a Filter at "/*" and gets involved only when there is a matching WebSocket endpoint. That's actually the end result I have in mind -- that endpoints should be deployable at any URI, without requiring a common prefix for WebSockets.
The developer has the freedom under this scheme to put websockets
anywhere under the URI space of the webserver, with the caveat that all
the websockets in the same web application will share the same root.
So, basically, its the same scheme as servlets.
>
> Request-time Endpoint Deployment -- currently the WebSocket implementation performs the handshake and selects the endpoint. It is not possible for an application or framework to get involved until after the connection has been established.
Maybe I'm misunderstanding here, but by providing a custom configuration
object, the websocket developer can intercept the handshake to
inspect/modify the handshake interaction. Such a custom configuration
object could equally be provided by a framework that sits on top of the
websocket API, and be selected by the developer.
For example, the server side developer can subclass
DefaultServerConfiguration and override modifyHandshake(), (and the
whole URI mapping scheme if he wants to !).
> An application should be able to initiate the handshake process by delegating to the WebSocket runtime in order to attempt an upgrade while also providing the Endpoint instance (or EndpointFactory) to use directly in case of a successful upgrade.
If I understand what you say, this is like calling
WebSocketContainer.connectToServer with a custom ClientConfigurationObject.
> The WebSocket implementation will check the headers, perhaps allow customization of sub-protocol/extension/origin checks, and return an HttpUpgradeHandler, which can then be used to call request.upgrade(handler). For what it's worth, this is possible in one way or another with existing implementations (Tomcat, Jetty, Glassfish) and is a very natural bridge between the Servlet and the WebSocket runtimes allowing an application to take anything available in the Servlet request, Servlet context, or any other places (e.g. DB) and pass it on to every Endpoint.
I'm thinking perhaps you didn't see the ability to customize the
handshake is indeed there? Let me know if I'm misunderstanding this.
Cheers,
- Danny
>
> I realize the last point is a new deployment option but I'm hoping it's more of an API refinement and not anything substantially different.
>
> Regards,
> Rossen
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation