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.
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.
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? 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.
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. 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. 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 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