Hi Danny-
I thought it might be something relatively easy to achieve but apparently not so as Joakim pointed out.
Thanks,
Rossen
----- Original Message -----
> From: "Danny Coward" <danny.coward_at_oracle.com>
> To: jsr356-experts_at_websocket-spec.java.net
> Cc: "Rossen Stoyanchev" <rstoyanchev_at_vmware.com>
> Sent: Wednesday, February 27, 2013 7:49:45 PM
> Subject: Re: [jsr356-experts] Programmatic handshake
> 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
>
> --
> Danny Coward
> Java EE
> Oracle Corporation