-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't unregister websocket when using decorators on ServerWebSocketContainer #8600
Labels
Milestone
Comments
aperinot
added
status: waiting-for-triage
The issue need to be evaluated and its future decided
type: bug
labels
Apr 19, 2023
artembilan
added
in: websocket
and removed
status: waiting-for-triage
The issue need to be evaluated and its future decided
labels
Apr 19, 2023
artembilan
added a commit
to artembilan/spring-integration
that referenced
this issue
Apr 19, 2023
Fixes spring-projects#8600 When we register a dynamic WebSocket endpoint and use a `WebSocketHandlerDecoratorFactory` such an endpoint is not removed on an `IntegrationFlow` destruction. The actual `WebSocketHandler` is decorated, however we still use an initial one for condition. * Refactor `IntegrationWebSocketContainer` to expose a `protected` setter for the `WebSocketHandler` which is called from the `ServerWebSocketContainer` after decoration **Cherry-pick to `6.0.x` & `5.5.x`**
garyrussell
added a commit
that referenced
this issue
Apr 19, 2023
* GH-8600: Fix WebSocket `removeRegistration` Fixes #8600 When we register a dynamic WebSocket endpoint and use a `WebSocketHandlerDecoratorFactory` such an endpoint is not removed on an `IntegrationFlow` destruction. The actual `WebSocketHandler` is decorated, however we still use an initial one for condition. * Refactor `IntegrationWebSocketContainer` to expose a `protected` setter for the `WebSocketHandler` which is called from the `ServerWebSocketContainer` after decoration **Cherry-pick to `6.0.x` & `5.5.x`** * Fix language in Javadocs Co-authored-by: Gary Russell <grussell@vmware.com> --------- Co-authored-by: Gary Russell <grussell@vmware.com>
garyrussell
added a commit
that referenced
this issue
Apr 19, 2023
* GH-8600: Fix WebSocket `removeRegistration` Fixes #8600 When we register a dynamic WebSocket endpoint and use a `WebSocketHandlerDecoratorFactory` such an endpoint is not removed on an `IntegrationFlow` destruction. The actual `WebSocketHandler` is decorated, however we still use an initial one for condition. * Refactor `IntegrationWebSocketContainer` to expose a `protected` setter for the `WebSocketHandler` which is called from the `ServerWebSocketContainer` after decoration **Cherry-pick to `6.0.x` & `5.5.x`** * Fix language in Javadocs Co-authored-by: Gary Russell <grussell@vmware.com> --------- Co-authored-by: Gary Russell <grussell@vmware.com>
garyrussell
added a commit
that referenced
this issue
Apr 19, 2023
* GH-8600: Fix WebSocket `removeRegistration` Fixes #8600 When we register a dynamic WebSocket endpoint and use a `WebSocketHandlerDecoratorFactory` such an endpoint is not removed on an `IntegrationFlow` destruction. The actual `WebSocketHandler` is decorated, however we still use an initial one for condition. * Refactor `IntegrationWebSocketContainer` to expose a `protected` setter for the `WebSocketHandler` which is called from the `ServerWebSocketContainer` after decoration **Cherry-pick to `6.0.x` & `5.5.x`** * Fix language in Javadocs Co-authored-by: Gary Russell <grussell@vmware.com> --------- Co-authored-by: Gary Russell <grussell@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Impacted artifact / version
spring-integration-websocket version 5.5.16
Even if not tested, the issue seems to be present in 5.5.17, and latest 6.X.X branch
Describe the bug
When adding decorator factories to the ServerWebSocketContainer, it is not possible to unregister the websocket endpoint.
When registering, the ServerWebSocketContainer code is as follow:
As you can see, the addHandler is called with the latest returned webSocketHandler from the list of decoratorFactories.
If no decoratorFactories are set, the websocketHandler used is the default IntegrationWebSocketHandler.
However, the unregister code in IntegrationServletWebSocketHandlerRegistry is as follow:
It tries to remove from the dynamicRegistrations by retrieving the handler with serverWebSocketContainer.getWebSocketHandler().
However the getWebSocketHandler() returns the default IntegrationWebSocketHandler, and not the decorated one, so the remove doesn't work, and it doesn't call the unregisterHandler() for the pattern.
To Reproduce
Expected behavior
The expected behavior shall be the unregistration of the endpoint.
Workaround
Here is a workaround to make it work as expected.
The text was updated successfully, but these errors were encountered: