-
Notifications
You must be signed in to change notification settings - Fork 38.8k
Description
Jean-Baptiste Nizet opened SPR-11305 and commented
Provide a websocket scope, which would work as the HTTP request and session scopes, but would last only for the duration of the web socket session. The callback could then initialize some beans in this scope, and the various @MessageMapping method could read and modify beans from this scope, maintaining some sort of conversation state linked to the websocket session. An alternative would be to maintain the request scope alive until the websocket session is closed, to be able to use the same request-scoped currentUser bean both in @RequestMapping and @MessageMapping methods.
The WebSocket session should be handled in a similar way as the standard HTTP session: be able to put, get and remove arbitrary attributes indexed by name in the WebSocketSession. When a MessageMapping-annotated method would be invoked, the associated WebSocket session would be stored in a ThreadLocal variable, just like it's done for the HTTP request scope with RequestContextHolder. Any method invoked from the same thread would thus be able to access the WebSocket session attributes thanks to the "WebSocketContextHolder" ThreadLocal, and a custom scope could be implemented in a similar way as the RequestScope.
This would provide a programming model which would be almost identical to the classical Spring-MVC model. An extension point for the initialization would still be necessary to transfer attributes from the request scope (like the principal, or any other value), to the WebSocket session scope.
Affects: 4.0 GA
Issue Links:
- Pass WebSocket session attributes in HandshakeInterceptor and expose them to MessageMapping methods [SPR-11566] #16190 Pass WebSocket session attributes in HandshakeInterceptor and expose them to MessageMapping methods
- Allow setting principal on connect [SPR-11228] #15853 Allow setting principal on connect
Referenced from: commits 2c4cbb6
6 votes, 10 watchers