I've been aligning the Tomcat code with this proposal and there are a
couple of things that need discussion.
I am working on the assumption that the following would be added to the
javax.websocket.server package:
public abstract class ServerContainer implements WebSocketContainer {
public static ServerContainer getContainer() {
// Implementation TBD
return null;
}
public abstract void deploy(Class<?> pojo)
throws DeploymentException;
public abstract void deploy(ServerEndpointConfiguration sec)
throws DeploymentException;
}
The first question is does getContainer() use the ServiceLoader API to
load the implementation? For consistency with ContainerProvider, I think
it should.
>>> ... 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.
> OK thanks Mark. Then I think this works too.
The second point is related to the above.
There is enough information if I make use of container internal API but
I'd like to avoid that if at all possible.
Therefore I'd like to add one more method to the above API:
public abstract void setRoot(Object root);
This method provides a mechanism for the implementation to identify the
root URI for endpoints deployed through the ServerContainer. For a
Servlet container the ServletContext would be passed in. For other
containers an appropriate object (or possibly null) would be passed in.
It would be necessary to call this method before calling either of the
deploy() methods.
Mark