Affects Version/s: 1.0
Fix Version/s: None
Section 6.4 explicitly restricts server endpoints from being deployed once the server is up and running:
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.)