On Sat, Aug 10, 2013 at 6:57 AM, Igor Urisman <igor.uris...@gmail.com>wrote:
> Dear all, > > 1. I see how to close a session from either end of the connection. That, > of course, leaves the underlying endpoint intact. Is there a way to > un-deploy an entire server endpoint so that no new connections can be made > to it? If so, will it close existing sessions? > Please check the API ( http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerContainer.html) That is the interface to the underlined websocket container implementation. The interface defines addEndpoint but no removeEndpoint or similar. > > 2. Is there a way to query the ServerContainer for deployed endpoints? I'd > like to do that to check that there isn't already one at a given path. The > only solution I've found so far is to try to deploy it and, if the generic > DeploymentException is thrown, parse the error message. Not great. > Again there is nothing on API level. Other mechanism is to keep track of endpoints registrations by providing ServerApplicationConfig ( http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerApplicationConfig.html) inspect the annotated endpoints and/or provide programatic endpoints and keep track of the paths. The latter can be exposed by ServerEndpointConfig getPath ( http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.html) > 3. What's the recommended way of binding an HTTP session to a Websocket > one? I was able to get this to work by using a custom > ServerEndpointConfig.Configurator class that augments the base > modifyHandshake() method by stashing the HTTP session in a ThreadLocal > variable. Seems like the linkage between the WebSocket session and the > HTTP session is so basic that perhaps there's a more straightforward way to > do this? > JSR 356 spec 7.2 7.2 Relationship with Http Session and Authenticated State That's it. The API allows you to get to the Http Session from HandShakeRequest ( http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html) On later stage (after connection is established) there is no API support. Storing something in ThreadLocal is a recipe for problems later if those http threads are pooled and not cleaned properly. > Many thanks in advance and apologies if this has been covered on this list > or I'm overlooking it in the docs. > IMHO, these questions should be asked in JSR 356 EG. One way is to file JIRA issues at https://java.net/jira/browse/WEBSOCKET_SPEC If you do please link those here. ... Since Mark is on EG, his opinion matters as well. cheers niki > -Igor. >
