Remove restriction on when a server endpoint can be deployed

[glassfishrobot]

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]

[glassfishrobot]

@glassfishrobot Commented
Reported by rstoyanchev

[glassfishrobot]

@glassfishrobot Commented
Issue-Links:
is duplicated by
WEBSOCKET_SPEC-241

[glassfishrobot]

@glassfishrobot Commented
martin_grigorov said:
This request is related to https://java.net/jira/browse/WEBSOCKET_SPEC-181.

[glassfishrobot]

@glassfishrobot Commented
rstoyanchev said:
Based on the experience with a similar request in Tomcat, I want to clarify what I have in mind is the ability to initiate an upgrade from a Servlet or Filter, which is different from deployment via ServerContainer.addEndpoint. Something along the lines of:

HandshakeRequest request = ...
HandshakeResponse response = ...

ServerContainer container = ... 

container.upgrade(request, response, endpoint);

The above is not a concrete proposal, it's just an example to make clear the intent of the request.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA WEBSOCKET_SPEC-211

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/websocket-spec/issues/211
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek