Re-sending to the public list as I probably can't reply to jsr356-experts..
----- Original Message -----
> From: "Mark Thomas" <mark_at_homeinbox.net>
> To: jsr356-experts_at_websocket-spec.java.net
> Sent: Monday, February 18, 2013 5:22:27 AM
> Subject: [jsr356-users] [jsr356-experts] Re: Cleaned up Configuration APIs
>
> On 16/02/2013 00:41, Danny Coward wrote:
>
> >> The use case I'm thinking of is a large application with lots of
> >> JARs that knows exactly which endpoints need to be deployed and does
> >> not want to incur the start-up delay that scanning requires.
> >
> > Hmm. I see the usecase is useful. What would you suggest ?
>
> Restore - in some form - javax.websocket.server.ServerContainer
+1
> > We could make a special web.xml init parameter that could either
> > list them, or alternatively could reference
> > ServerApplicationConfigurations
> > which could supply the specific endpoints.
>
> I'd prefer a purely programmatic approach. Limiting this to something
> callable via a ServletContextInitializer (rather than at any point in
> time) would be fine with me.
I think most developers would prefer a purely programmatic approach over a web.xml init parameter.
At present the WebSocket deployment options are simply too restrictive by comparison with the Servlet API, which offers declarative mappings in web.xml and programmatic deployment through ServletContainerInitializer in addition to annotations. The only way to deploy server WebSocket endpoints is through annotations or via ServerEndpointConfiguration. However, typical Servlet applications rely on Listener/Servlet lifecycle methods, or on ServletContainerInitializer, if using Servlet 3, to perform initialization. The SCI scan is too early in the lifecycle and doesn't fit well with facilities existing applications have. Should I not be able to write one ServletContainerInitializer that registers Filters, Servlets, and WebSocket endpoints?
> > And a related question, is this your primary usecase for
> > programmatic deployment ? i.e. if we solved the use case, would you still want
> > it to be in the spec for some other reason ?
>
> Yes, this is my primary use case. With my VMware hat on, the Spring
> folks would like a purely programmatic approach too. I think Rossen
> raised this on the public list.
One additional point is that at present it is only possible to deploy to static URI templates. This is a significant limitation! Consider that a Servlet can be deployed to "/foo/*" or even "/" and is allowed to handle the sub-URI space as it sees fit. Some applications will be fine with the present arrangement but it won't work in general. A content management system might need to expose a WebSocket endpoint at a URI that cannot be known at development and hence cannot be built into an annotation or even a ServletContainerInitializer, which must provide a static URI template path as well.
I am not proposing the same mapping options as for Servlets but rather that the API provides some way to initiate a handshake and accept an Endpoint instance for it. This is a very simple idea really and Jetty (for example) provides such an option [1]. Having this would allow a single Servlet to serve both REST and WebSocket requests side by side as it sees fit.
Rossen
[1]
https://github.com/eclipse/jetty.project/blob/master/jetty-websocket/websocket-servlet/src/main/java/org/eclipse/jetty/websocket/servlet/WebSocketServletFactory.java