Hello all,
I didn't get much feedback on this, so we have been trying it out
ourselves to make sure it both resolves the holes in the existing API
and provides all the same functionality we here in the expert group have
talked about. So far so good.
So I've checked this into the trunk and will be updating the spec based
on the cleaned up API so we can keep things moving and get to some of
the other deployment related issues quickly.
Thanks,
- Danny
On 2/12/13 1:39 PM, Danny Coward wrote:
> Hi folks,
>
> As promised, here is a cleanup of the configuration APIs. For
> background, please take a look at the email I sent last week
> "Reworking Configuration/Deployment APIs". In sum, programmatic
> deployment was very heavyweight (almost unusable), and there was too
> much scope for altering configuration at the wrong time.
>
> This proposal addresses those two issues by tweaking the
> ServerApplicationConfiguration programmatic endpoint deployment, and
> refactoring the *Configuration classes so that the configuration data
> is immutable, while the configuration behaviors remain overridable.
>
> Once we've cleaned this up, we can move quickly on to some of the
> other requests and clarifications on this bit of the API.
>
> To summarize the changes in this proposal:-
>
> 1) ServerApplicationConfiguration.getEndpointConfigurationClasses has
> changed to scan for Endpoints and return ServerEndpointConfigurations.
> This fixes the problem with programmatic endpoint deployment on the
> server.
> 2) Instead of the mutable Default* implementations of the
> ServerEndpointConfiguration and ClientEndpointConfiguration interfaces
> that developers were able to subclass arbitrarily, there are now
> *Builder classes for the *Configuration interfaces, and the Default*
> implementations have now gone. This allows the same configuration
> information to be supplied as before, but only at deployment time, and
> means the configuration objects are now immutable. As a bonus, the
> builder pattern is more extensible for future spec versions that may
> add more configuration data.
> 3) The interceptor methods for the opening handshake (and ability for
> the developer to supply any other arbitrary logical-endpoint-scope
> processing) have been factored out into separate *Configurator
> interfaces that the developer can implement and supply - one for the
> client side and one for the server side.
>
> There are various ways to review this. Probably the best is to look
> from the developers' perspective by looking at the examples. Since we
> are late in the spec cycle, I wanted to be sure this rework is
> equivalent, works and addresses the issues, I written out examples of
> programmatic and annotated endpoints, client and server side, both
> vanilla and more exotic.
>
> Here is the example code you can browse directly
> <http://java.net/projects/websocket-spec/sources/source-code-repository/show/branches/config-api-experimental-handshakeconfigurator-builder/javax.websocket-api-1.0-b11/src/main/java/examples?rev=179>.
> Look in particular at deploying to the server
> <http://java.net/projects/websocket-spec/sources/source-code-repository/content/branches/config-api-experimental-handshakeconfigurator-builder/javax.websocket-api-1.0-b11/src/main/java/examples/MyServerDeployment.java?rev=179>,
> and deploying to the client
> <http://java.net/projects/websocket-spec/sources/source-code-repository/content/branches/config-api-experimental-handshakeconfigurator-builder/javax.websocket-api-1.0-b11/src/main/java/examples/ClientMain.java?rev=179>.
>
> I have posted the javadoc here
> <http://java.net/projects/websocket-spec/downloads/download/NewConfiguration/configuration-experimental-configurator-builder.zip>.
> Note this API is based on the public draft API v011, not v012.
>
> You can also look directly at the sources if you like: its in the spec
> repo under /branches/config-api-experimental-handshakeconfigurator-builder
>
> Please take a look as soon as you are able and let me know if you see
> problems with this proposal.
>
> Thanks !
>
> - Danny
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation