-
Notifications
You must be signed in to change notification settings - Fork 512
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
Provide The Ability to Exclude Global RetryListeners #211
Comments
A simple work around would be to add @Bean
RetryListener noOpListener() {
return new RetryListenerSupport();
} and |
It's a little funky and will require documentation to the effect... I'll give it a go, but my initial reaction was to migrate to declarative code. |
May I handle this issue? please assign to me~ I'll create PR soon! |
Well, this is what is said on that option:
I suggest to make ignoring global listeners is to modify the logic to react to something like this: Right now it fails like:
So, that @ssjf409 , Feel free to provide a contribution, but we assign issues only to team members. Thanks |
Hi. akenra. I saw your PR. Before I created PR, I thought two options I came up with two different implementations of @artembilan's suggestion. However, from the user's perspective, it felt strange to have to know how it behaves when the So I create this PR. |
I wish there was no a The |
@artembilan, Thanks for the clear guide. |
Hey,
I recently encountered this case whereby methods which are annotated
@Retryable
with no list oflisteners
being passed automatically has them added to the executingRetryTemplate
at runtime. Upon reading up on the source, this is expected, sinceRetryListener
instances which are injected into the application context become, so called, "global" listeners. Unfortunately, this has unexpected consequences in some cases, and it would be awesome to also be able to specify a list ofexcludeListeners
in the@Retryable
annotation.I know it's feasible to also pass a label and introspect it at the listener level to make the execution decision, but that, afaik, isn't the intended purpose of that parameter.
The text was updated successfully, but these errors were encountered: