https://issues.apache.org/bugzilla/show_bug.cgi?id=55314
--- Comment #5 from rstoyanc...@yahoo.com --- Mark, many thanks for the change although it looks like we had different ideas about the end result. From what I can see the solution makes it possible to call ServerContainer.addEndpoint at runtime after which WsFilter handles matching WebSocket handshake request. What I had in mind is the ability to create a Servlet that can do centralized HTTP request processing including WebSocket handshake requests, i.e. instead of WsFilter. It's what I meant with the comparison to the Tomcat 7 WebSocketServlet. The obvious issue is that JSR-356 doesn't provide this, at least not yet. The client-side connectToServer is similar in spirit but nothing like it on the server side. I imagined it would be something like: WsHandshakeRequest wsRequest = ... WsHandshakeResponse wsResponse = ... WsServerContainer wsContainer = ... wsContainer.upgrade(wsRequest, wsResponse, endpoint); So any intermediate solution would have to be Tomcat specific. Just a thought here on maybe providing a separate interface marked clearly as an intermidiate solution that will remain stable until the spec has an alternative and that will be deprecated afterwards, something like: NonCompliantWsServerContainer container = ... container.upgrade(wsRequest, wsResponse, endpoint); -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
