Hi folks,
I looked across some of the EE specs to see how our deployment mechanism
compared, in part inspired by Mark's pointer to the EL spec, and by
feedback from our RI lead who is very familiar with JAX-RS. Now is a
good time to review our deployment mechanism before we finalize things
for public draft. Fortunately, comparing with other EE specs gives us a
range of options to be consistent with. Unfortunately, it gives us a
range of options to be consistent with :)
(On the client side, things are simpler: I'm not proposing a change
there: we get a hook to the ClientContainer and programmatically deploy
the endpoints using the API. I would like to include the suggestion to
return the Session from this call, and consequently, define this as a
blocking call).
On the server side, currently we are using
ContainerProvider.getServerContainer() as the entry point, and
serverContainer.publishServer() for programmatic endpoints. For POJOs,
we expect the web container to scan the WAR file.
This means we have two different approaches for programmatic endpoints
and POJOs: for programmatic endpoints you have the advantage that you
can deploy any or all of them at will, but you have to code it yourself.
On the other hand, all your POJOs in the WAR get deployed whether you
want them all or not.
Ideally, I think it would be helpful to developers if deployment was
consistent between POJOs and programmatic endpoints, if deploying simple
cases should require no configuration at all, and it was possible to
control which endpoints in a WAR were deployed.
So I'm suggesting a change to the server deployment to meet these goals,
which goes like this:-
1) On deployment, the websocket server scans the WAR file for
programmatic endpoints and POJOs. If no other configuration information
exists in the WAR file (see 2) then all the programmatic endpoints and
all the POJOs in the WAR file are deployed on startup.
2) We introduce an ApplicationDeployment type into the websocket API for
developers who want finer grained control over which endpoints in the
WAR file get deployed. This type is implemented by developers and
co-packaged in the WAR file. Its function is to return on demand a list
of all the programmatic endpoints and POJOs the container should deploy
at deployment time. The exact API semantics TBD for now.
3) We no longer need the ServerContainer.publishServer() method, and
consequently, there is no need for the entry point
ContainerProvider.getServerContainer().
An alternative to 2) is to define a static configuration mechanism, like
a deployment descriptor. These seem to have gone out of fashion in the
EE platform, but it could fulfill the same function (and is consistent
with several sister specs).
Please let me know your thoughts on this approach, I'd like to clean
this up quite soon,
Thanks,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation