Dave Syer
Dave Syer
I see what you mean. I'm not sure why you would want to set it to `false` in that case (that's the default anyway). Do you have an actual use...
I guess we could change the signature if we are going to bump to a new major version. Would that solve your problem? Under what circumstances would you care? Why...
Fair enough. But it's easy to work around isn't it? I guess that's what you meant by "clunky".
Sure, but you would put those 6 lines in a convenience class and only use one line in practice, if this pattern was common. We can put such a convenience...
Do you have an actual use case where that matters?
I guess you need to create a bean of type `RetryConfiguration` (and enable annotation processing). It's a long time since anyone even thought of trying it. Does that work for...
You could just use the existing methods for this, I guess, but you just want a neater way to do it as a one liner?
Interesting idea. Spring Retry has no dependency on HTTP though. So you would have to implement it as a `RestTemplate` interceptor (for example - same approach would work for other...
You might need to provide a custom `BackoffPolicy` or `RetryPolicy` (not sure). But I think it's doable with the retry context as it is already implemented.
I rebased your work onto master. See PR: https://github.com/ashamukov/spring-retry/pull/1 (or alternatively reset your own branch to https://github.com/dsyer/spring-retry/tree/ashamukov-async-retry).