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