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

Add ErrorHandler strategy for MessageListener containers [SPR-6142] #10810

Closed
spring-projects-issues opened this issue Sep 22, 2009 · 1 comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Mark Fisher opened SPR-6142 and commented

The ErrorHandler interface was added for TaskScheduler implementations in 3.0. However, the interface itself is completely generic and could also be used for handling uncaught errors (other than JMSExceptions, which are already handled by the JMS ExceptionListener) in a MessageListener container rather than logging only.

First, the ErrorHandler interface should be moved from the 'scheduling' package to 'util'.


Referenced from: commits 616a48a, dedecf7

@spring-projects-issues
Copy link
Collaborator Author

Mark Fisher commented

Moved the ErrorHandler strategy interface to org.springframework.util:
https://fisheye.springsource.org/changelog/spring-framework?cs=1964

This also required some changes to classes/methods that were previously package-protected, since the dependency is shared across multiple sub-packages under 'scheduling'.

@spring-projects-issues spring-projects-issues added in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0 RC1 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant