Reading the HandshakeRequest javadoc this is written:
So its valid to have NO HttpSession assigned to a JSR356 request.
But Wicket seems to "expect" this because in JavaxUpgradeHttpRequest the HttpSession is extracted from the userProperties which is not there, if it was "null" in the HandshakeRequest.
In the processing the chain will reach the AbstractWebSocketProcessor constructor which calls
which is going to fail here because there is no HttpSession on the crafted request used here.
I wonder why the sessionId is taken from the HttpSession at all - shouldn't it be the JSR356 session id which you can get with session.getId().
If you look e.g. at the IWebSocketConnectionRegistry javadocs most methods have their sessionId argument documented with:
but actually the HttpSession id is used instead of the WebSocket sessionId - which is a totally different one.
So i am proposing to use the "real" websocket session id here taken from the constructor call:
where there is the session argument where session.getId() actually returns the websocket session id which can last longer and is 100% there - the HttpSession must not be there at all as written.
Unfortunately the javadoc on IWebSocketConnectionRegistry for
does not state which "sessionId" is meant here - i guess its the HttpSession - in that case please clarify the JavaDocs here.
The code maybe need to "track"the HttpSession id to handle that usecase - but in an optional way because it may not be there.