On 26/02/2013 13:52, Danny Coward wrote:
> Hi Mark and Rossen,
>
> OK, let me change tack here, and make sure I understand what you are
> both proposing, and that in fact you agree with each other :)
>
> In addition to the existing scan + ServerApplicationConfiguration
> mechanism, you'd like (* denotes new API)
>
> ServerContainer* extends WebSocketContainer {
> public void deploy(Class<?> pojo) throws DeploymentException;
> public void deploy(Class<? extends Endpoint> programmaticEndpoint,
> ServerEndpointConfiguration sec) throws DeploymentException;
> }
>
> So from some some kind of deployment initialization code you would write
>
> ServerContainer* sc = ServerContainerProvider*.getServerContainer();
> sc.deploy(...); ///etc
>
> and your placing of such deployment initialization code would be:
> 1) no webcontainer: not defined
> 2) web container: using some existing servlet mechanism, e.g. inside a
> ServletContextListener configured in the web.xml.
>
> Is that right ?
Yes.
The one slight change is that with the new config APIs the second method
becomes:
public void deploy(ServerEndpointConfiguration sec)
throws DeploymentException;
> If so, we are currently trying to restrict there to be one
> ServerContainer instance per websocket application. Do you have enough
> context under the ServerContainerProvider*.getServerContainer(); call to
> do that ?
Yes. Currently I use the current context classloader (which is the web
application class loader in a servlet container) to ID the right
ServerContainer / determine I need to create a new one.
Mark