Section 6.4 explicitly restricts server endpoints from being deployed once the server is up and running:

Developers may deploy server endpoints programmatically by
using one of the addEndpoint methods of the ServerContainer
interface. These methods are only operational during the
application deployment phase of an application. Specifically,
as soon as any of the server endpoints within the application 
have accepted an opening handshake request, the apis may not
longer be used. This restriction may be relaxed in a future
version.

There are cases however when it is useful to have consolidated handling of HTTP requests including WebSocket handshake requests. For example SockJS (a protocol for WebSocket fallback options) expects URLs (see the "Session URLs" section) with the pattern "/endpointPrefix/<server>/<session>/<transport>" where <transport> can be HTTP-based (e.g. HTTP streaming, long polling) or WebSocket. The most natural way to implement this is to create a single servlet SockJS that handles all requests under ``"/endpointPrefix"including requests for"/endpointPrefix///websocket"`. This is known as front servlet and it's what virtually all web frameworks have.

I can imagine there are other cases where it is not possible to determine the URL at which an endpoint should be deployed at startup (e.g. SAAS product that lets configure and use cloud-based services). It would be useful to have more examples here.

It's worth pointing out that WebSocket APIs in Java and outside of Java consistently provide a way to do this, i.e. integrate WebSocket handshakes into existing HTTP request handling mechanisms (Jetty 9, Netty, vert.x, socket.io, etc.)

Affected Versions

[1.0]