Introduce minimal retry functionality as a core framework feature

[fmbenhassine]

This commit introduces a minimal core retry feature in Spring Framework. It is inspired by Spring Retry, but redesigned and trimmed to the bare minimum to cover most cases.

The main entry point is the RetryTemplate class, which is designed in a similar fashion to other templates provided by Spring. The package is minimal on purpose to keep its usage as simple as possible (see examples in RetryTemplateTests). It is also focused only on stateless retries for now, but can be extended with other retry operations as well.

[sbrannen]

Hi @fmbenhassine,

First and foremost, thanks for putting this PR together! 👍

I took a quick look, added a few comments, and asked a few questions (as food for thought).

And we will also discuss the proposal within the team.

Cheers,

Sam

[sbrannen]

In the description of this PR, you state the following.

It is also focused only on stateless retries for now, but can be extended with other retry operations as well.

For future extension, do you envision extending the contract of RetryPolicy?

If so, how?

If not, how do you envision extending the feature set "with other retry operations"?

[sbrannen]

How do you envision a user possibly being able to implement a retry policy conditionally based on the actual exception thrown?

[fmbenhassine]

Yes, I don't exclude extending the contract of RetryPolicy with anything that we think essential for this first iteration. The list of exceptions to retry/exclude could be part of the retry policy contract.

By "can be extended with other retry operations" I was referring to stateful retries. Stateful retries require some sort of context (similar to the one currently in Spring Retry). But instead of overwhelming the RetryOperations interface with both stateless and stateful operations, I envision stateful retries to be defined in a specialization of RetryOperations (something like StatefulRetryOperations with additional methods dealing with a context). I am trying to follow the ISP here, as most users won't probably need stateful retires, and therefore should not be forced to implement those methods. Do you agree?

[fmbenhassine]

I pushed a change set that enriches the retry policy with a method that allows user to provide a predicate on the exception and specify the retry condition. I believe a predicate is more flexible than two lists of exceptions to include/exclude as it is currently in Spring Retry.

[fmbenhassine]

Thank you for the review, @sbrannen !

I added a couple of inline comments and I will update the PR accordingly.

[fmbenhassine]

I updated the PR with the following changes:

• Add/Use a specific RetryException in the API instead of the generic Exception
• Add RetryCallback interface with a logical name for diagnostics purposes
• Improve RetryPolicy with the ability to specify which exceptions to retry based on a Predicate<Exception>

I find this new version to be more coherent and consistent with other templates in terms of structure and API. Looking forward to the team's thoughts on this!