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 <http://www.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
>