Igor Urisman <igor.uris...@gmail.com> wrote: >Dear all, Answering from a JSR356 perspective. Tomcat could add these features outside of the SPEC.
>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? No. > If so, will it close existing sessions? N/A > >2. Is there a way to query the ServerContainer for deployed endpoints? No. >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. >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? They are deliberately decoupled. The user proprties on the session is probably ta better place but be aware that the http session may expire while the web socket session still exists. > >Many thanks in advance and apologies if this has been covered on this >list >or I'm overlooking it in the docs. There is some background on the why of the http session aspect on the SPEC users list. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
