I have 2 main concerns about the 1.0 API I'd like to see discussed.
First, the WebSocketContainer (aka, the Client Container) has no clearly defined lifecycle.
When is it to init/start?
When is it to finish/stop?
Yes. I think the thinking was that some (most) developer may use the same instance, but if you want to have a couple instances with different default properties, you can.
Second, ContainerProvider.getWebSocketContainer() is to return a new instance of a javax.websocket.WebSocketContainer on every call. (per the javadoc)
Is this really what is intended?
Or, like the server side's javax.websocket.server.ServerContainer, is there to be only 1, and each call to ContainerProvicer.getWebSocketContainer() returns the same instance (with the only nuance being that on a web container, each webapp has its own WebSocketContainer instance)
If the implementation has resources that are managed to support the client portions of the WebSocketContainer, when and how do we clean up those resources? As there is no WebSocketContainer lifecycle [such as a .start() and .stop()] then there is no real way to know if the user of the WebSocketContainer is done with it.
I think that would be reasonable to do in the meantime. Otherwise, perhaps there is a way to use the WebSocketContainer instance as a facade a pool of the 'real' container instances or something.
Since API changes are not likely to occur, should we implement some sort of safeguards into the ContainerProvider.getWebSocketContainer() if too many WebSocketContainer references have been requested?
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty <http://eclipse.org/jetty/> - cometd.org <http://cometd.org/>
[jsr356-users] [jsr356-experts] Re: WebSocketContainer lifecycle concerns