users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re: Proposed Final Draft

From: Joe Walnes <joe_at_walnes.com>
Date: Thu, 7 Mar 2013 11:18:04 -0600

Excellent work!

One question for clarification:

* Section 5.1: It is not clear what the concurrency restrictions are on
Session and RemoteEndpoint instances. Can methods be called on these
concurrently from different threads? For example, async results from other
threads. Or one Endpoint instance using Session.getOpenSessions() to
communicate with other RemoteEndpoints.

And a suggestion to make it easier to understand:

* Section 6.4: Can we add something along these lines: "The
getServerContainer() static method of ServerContainerProvider class can be
used to obtain an instance of ServletContainer."

Thanks
-Joe



On Wed, Mar 6, 2013 at 6:26 PM, Danny Coward <danny.coward_at_oracle.com>wrote:

> Hi folks,
>
> I've posted the proposed final draft of the specification to the usual
> place and send it over to the JCP PMO.
>
> Thankyou for your attention, help and expertise ! We have accomplished a
> great deal in a relatively short amount of time.
>
>
> http://java.net/projects/websocket-spec/downloads/directory/Spec%20javadoc%20Drafts/Proposed%20Final%20Draft
>
> I have tagged the PFD of the API here:
>
> tags/javax.websocket-api-1.0-rc1
>
> What happens next ?
>
> A number of us are finalizing our implementations of the API, and we
> (Oracle) are working hard to fill out the TCK. These activities may yet
> throw up some issues that will need to deal with (including a possible implementation
> issue <http://java.net/jira/browse/WEBSOCKET_SPEC-165> about the new
> ServerContainer and how to link instances thereof to the ServletContext),
> so please stay tuned for those.
>
> There is room in the JCP process (http://jcp.org/en/procedures/jcp2#2.3)
> to address these as we prepare the Final Draft. The JCP process document
> characterizes the kind of issues that can be addressed at this point as
> those where the specification is '"underdefined, incomplete, or ambiguous",
> so we will use our best judgement (in particular with respect to the Java
> EE schedule) to be very conservative in our approach to any spec changes
> after this point, should any requests come up.
>
> Thanks and stay tuned,
>
> - Danny
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>