On 21/02/2013 01:03, Danny Coward wrote:
> 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 agree with that. I think Rossen would prefer to be able to deploy new
endpoints at any time.
> A) a programmatic API that can be called during application deployment.
> B) Some expansion of ServerApplicationConfiguration that doesn't depend
> on a scan.
My instinctive preference is for A.
> 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.
I think this should also be possible with a ServletContextListener.
> - 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").
For consistency with ContainerProvider I think there should be a static
method on a new class e.g.
javax.websocket.server.ServerContainerProvider.getWebSocketServerContainer()
API of WebSocketServerContainer TBD but it could extend
WebSocketContainer and add some server specific methods. Currently
Tomcat adds:
public void publishServer(Class<? extends Endpoint> endpointClass,
String path,
Class<? extends ServerEndpointConfiguration> configClass)
throws DeploymentException
and
public void publishServer(Class<?> pojo, ServletContext ctxt,
String wsPath)
i.e. one method for Endpoints and one for POJOs. I doubt we want to use
these exact method signatures in the API but it should be something
along those lines (and be consistent with the client side methods on the
super class).
> - third: we would need to throw (runtime?) exceptions if the
> programmatic deployment API was called at the wrong time.
Yes.
> 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.
Hmm. Given that WebSocket implementations are meant to be idependent
form the container, I don't see how a WebSocket implementation is going
to be able to pick up that init parameter without using something such
as a ServletContextInitializer or a @WebListener - both of which require
some form of scan to be picked up.
> I think A) and B) both meet the requirement. Right ?
I don't see how B meets the no scan requirement.
> Could we live with B) ?
I think not.
Mark