Thanks for the comments. Since Jetty's WebSocketServlet can be deployed at any high level URL pattern (e.g. "/main/*" or "/"), in effect it's possible to expose a WebSocket endpoint at URLs that do not need to be determined statically at compile time. Furthermore, WebSocketFactory/WebSocketCreator are easily usable without Jetty's WebSocketServlet, which means that *any* Servlet can be the bridge between the Servlet API and the WebSocket API.
Rossen
----- Original Message -----
> From: "Joakim Erdfelt" <joakim_at_intalio.com>
> To: users_at_websocket-spec.java.net
> Sent: Tuesday, February 19, 2013 1:00:15 PM
> Subject: [jsr356-users] Re: Subject: [jsr356-experts] Re: Cleaned up
> Configuration APIs
> Since I wrote this section of code for Jetty, lemme explain a bit how
> it works.
> In jetty, we have a WebSocketServlet that needs to be extended to
> provide the glue between the websocket and the servlet api.
> This in turn handles the upgrade logic and also exposes a
> WebSocketFactory that can be used to manage things.
> By default, the upgrade logic will go thru a WebSocketCreator object
> that provides (advanced) usage for creating/initializing websocket
> objects of the developers own choice based on various information
> present in the UpgradeRequest object, and allowing them to manage
> the UpgradeResponse flow as well.
> The WebSocketFactory has a basic WebSocketCreator that assumes 1
> websocket per servlet.
> The WebSocketFactory.register(Class websocket) call will register
> your websocket of choice to this default WebSocketCreator.
> However, if the developer wants to control the creation of websockets
> they can provide their own WebSocketCreator and use whatever logic
> they want to create the websockets they want. This means that for 1
> WebSocketServlet you can serve as many different websockets as you
> deem fit.
> This works equally as well with standard a websocket with no
> extensions and complex websocket creation scenarios such as within a
> Mux extension.
> --
> Joakim Erdfelt < joakim_at_intalio.com >
> webtide.com
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
> On Tue, Feb 19, 2013 at 10:41 AM, Rossen Stoyanchev <
> rstoyanchev_at_vmware.com > wrote:
> > 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
>