Skip to content
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

Customize STOMP ERROR frame [SPR-12732] #17329

Closed
spring-issuemaster opened this issue Feb 18, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Feb 18, 2015

slash3tc opened SPR-12732 and commented

The ability to customize which headers are present in the ERROR frame would allow for better front-end handling for error conditions that may have been triggered from ChannelInterceptors.

Currently, if an exception occurs in a channel interceptor (such as if you are attempting to control subscription events based on arbitrary logic), an ERROR frame is sent back to the client from StompSubProtocolHandler.sendErrorMessage.

The ERROR frame simply contains the throwable.getMessage() in a header which causes awkward client side handling.

Could a StompProtocolErrorHandlerStrategy be created to allow for message customization?


Affects: 4.1.4

Issue Links:

  • #15519 Provide mechanism for tracking failed messages in STOMP protocol support
  • SEC-2881 Provide an exception handling mechanism for ChannelSecurityInterceptor

Referenced from: pull request #743

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 18, 2015

slash3tc commented

Possibly related to #15519 ?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 19, 2015

Rossen Stoyanchev commented

Seems like a good idea. Exceptions may arise on the inbound and on the outbound sides in the StompSubProtocolHandler resulting in an ERROR frame being sent to the client. Furthermore, an ERROR frame may be sent from StompBrokerRelayMessageHandler for example if the connection is lost or we may even receive an ERROR frame from the broker which we relay back to the client. Providing more insight into what the error represents would be useful.

What kind of customizations do you have in mind? It would probably make sense to have some default implementation.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 22, 2015

slash3tc commented

Hi Rossen!

I have submitted a pull request (#743) with the type of feature that I believe solves this issue. Supplied is a strategy interface, a default implementation for StompSubProtocolHandler and some additional tests.

This covers the feature and allows for configuration BUT, I could not find a decent way to be able to access the StompSubProtocolHandler instance directly from the configuration point of classes extending WebSocketMessageBrokerConfigurationSupport after using @EnableWebSocketMessageBroker or @EnableWebSocketMessageBroker to actually allow developers to call StompSubProtocolHandler.setStompSubProtocolErrorHandler(..).

Let me know what you think!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 23, 2015

Rossen Stoyanchev commented

Comments added directly under the PR.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 15, 2015

Rossen Stoyanchev commented

I've added a StompSubProtocolHandler. If you could please give it a try.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.