Hi folks,
OK so if I understand it from Mark and Rossen, the usecase for
programmatic deployment is to be able to deploy any server endpoint
(programmatic or annotated) contained within the WAR, irrespective of
whether there is a scan on the WAR. And if I understand correctly, it is
sufficient only to be able to do so at application deployment time.
I think its right for this version not to be contemplating being able to
programmatically deploy endpoints at any arbitrary time in the lifetime
of an application. I'm just not sure what side effects there are of
dynamically adding to an application at runtime, and we'd probably have
to think of an analogous undeploy mechanism. That sort of thing I think
belongs in some future version. Though of course containers can always
provide their own ways to do this now, if they are brave !
But back to the requirement: currently, we have developer provided
ServerApplicationConfigurations to which the implementation passes the
results of the archive scan and out of which the implementation gets a
collection of endpoints (annotated endpoint classes or EndpointConfig
instances for programmatic endpoints).
So to meet the requirement (which I would like us to), we have two ideas:-
A) a programmatic API that can be called during application deployment.
B) Some expansion of ServerApplicationConfiguration that doesn't depend
on a scan.
To get into A) a bit more, we would need a few extra things as well as
the actual methods:
- first, a bootstrap point to be able to call the programmatic API at
the correct time: bootstrapping the correct time to make the call in the
lifecycle could be done inside a developer provided
ServletContextInitializer.
- second: to obtain a reference to the WebSocketContainer I guess the
spec could define a named ServletContext attribute, for example
ServletContext.getAttribute("javax.websocket.server.ServerContainer").
- third: we would need to throw (runtime?) exceptions if the
programmatic deployment API was called at the wrong time.
To get into B) a bit more, we could define new interface, analogous to
ServerApplicationConfiguration, let's say
"NonScanApplicationConfiguration" just for now, with methods.
NonScanApplicationConfiguration
- Set<ServerEndpointConfiguration> getEndpointConfigurations();
- Set<Class<?>> getAnnotatedEndpointClasses();
Developer could implement these at will, package them in the WAR same as
ServerApplicationConfiguration. The spec would need to define a web.xml
context-param name, say
"javax.websocket.server.NonScanApplicationConfiguration", and value a
comma separated list of developer implementations thereof. The container
picks them up (instead of doing a scan) and build the deployment list
from there.
I think A) and B) both meet the requirement. Right ?
At first I thought the programmatic API was going to turn out simpler,
but when I look at all the pieces, I'm thinking the second approach B)
is simpler. Its seems to be more consistent with the existing scan based
approach, the mechanism is more self-contained in the websocket spec,
and the callback enforces the 'deploy at application initialization
time' better. Also, if we do a full dynamic deployment API in the
future, we'd have to fit it round this more limited API.
Could we live with B) ?
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation