Hi Rossen,
Its going to take me some time to digest what it is you're asking for in
detail, but the shorter answer from my perspective is that it looks to
me that we don't have time to properly design or implement this for
version 1.0.
The background you likely missed because you joined us later that most
of the others is that in order to be part of Java EE 7 we ended up
having to pull in our schedule, requiring us to complete a version of
this JSR quite quickly. And we have already deferred some functionality
to the next version so we could get on the train, even as we have agreed
on quite a large number of features, and hit (I think) the goals of the
JSR itself.
I know we have been refactoring API and working in smaller feature
additions over the last couple of months, but these have been
(exclusively, I think), things that were requested prior or shortly
after public draft in December, or in some cases included in a previous
draft - like programmatic deployment. Amid a lot of active work to
tighten up on the functionality we have already defined.
So, I'm very sorry to be the websocket Grinch, but I would like to defer
this feature until the next version.
Once we have submitted this version to the JCP, I would like to have a
larger discussion of websocket.next, the features and the timing. For
those of you concerned about being locked into Java EE, we can revise
websockets independently of the EE platform.
Cheers,
- Danny
On 2/27/13 7:27 AM, Rossen Stoyanchev wrote:
> I would like to propose a programmatic way of initiating a handshake:
>
> public interface ServerContainer {
> // ..
> boolean doHandshake(HandshakeRequest req, HandshakeResponse res, ServerEndpointConfigurator sec);
> }
>
> If HandhsakeRequest/Response had methods to expose the raw request/response:
>
> public interface HandshakeRequest {
> // ..
> <T> T getRequest(T requestClass);
> }
>
> public interface HandshakeResponse {
> // ..
> <T> T getResponse(T responseClass);
> }
>
> then I believe (but could be wrong) the logic for doHandshake should be very straight forward:
>
> boolean doHandshake(HandshakeRequest req, HandshakeResponse res, ServerEndpointConfigurator sec) {
>
> HttpServletRequest servletRequest = request.getRequest(HttpServletRequest.class);
> HttpServletResponse servletResponse = response.getResponse(HttpServletResponseclass);
>
> // Check or set headers
>
> // Check origin, subprotocols, and obtain endpoint instance via ServerEndpointConfigurator
>
> // Create HttpUpgradeHandler and call servletRequest.upgrade(handler)
>
> return true;
> }
>
> Why does this matter?
>
> 1) We already have a concrete proposal for programmatic deployment that will allow Servlet developers to use Servlet container lifecycle points. This continues the same theme by allowing Servlet developers to initiate the handshake from a Servlet or Filter. Scott Ferguson referred to it as the "launch websockets from a plain servlet" option in a recent discussion.
>
> 2) Virtually all pre-existing Servlet container WebSocket APIs including Tomcat, Jetty, Glassfish, and Resin have some such option. That's a good indication that having this option makes sense.
>
> 3) There are many Java products and frameworks installed as a single Servlet that serve as the "front controller" for all incoming requests at a specific URI space. This option would allow them to also integrate WebSocket handshakes directly into their processing without requiring a separate artifact, i.e. ServerEndpointConfigurator, which is more of an API than an SPI.
>
> 4) This completes the bridge between the Servlet and the WebSocket APIs without introducing a dependency. On one side the Servlet API offers the HttpServletRequest upgrade method. On the other WebSocket implementations *somehow* call it. It makes sense to have a public API on something that all implementations will have to do anyway.
>
> I believe this is very important for JSR-356 adoption beyond just applications and should be simple enough to do. Or to look at it from the opposite side, are there any reasons not to have this?
>
> Rossen
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation