Introduction

Hardcoding retry limits in a @Retryable annotation works for a demo, but it becomes awkward as soon as different environments need different values. Spring Retry supports property-based configuration directly, so you can keep retry behavior externalized in application.yml or application.properties without giving up the convenience of annotations.

Use Expression Attributes Instead of Fixed Values

The key detail is that @Retryable has expression-based attributes such as maxAttemptsExpression, and @Backoff has delayExpression. Those are the ones that can read property placeholders.

1app:
2  retry:
3    max-attempts: 4
4    delay-ms: 1500

1import java.io.IOException;
2import org.springframework.retry.annotation.Backoff;
3import org.springframework.retry.annotation.Recover;
4import org.springframework.retry.annotation.Retryable;
5import org.springframework.stereotype.Service;
6
7@Service
8public class RemoteClient {
9
10    @Retryable(
11        retryFor = IOException.class,
12        maxAttemptsExpression = "${app.retry.max-attempts}",
13        backoff = @Backoff(delayExpression = "${app.retry.delay-ms}")
14    )
15    public String fetchData() throws IOException {
16        throw new IOException("temporary failure");
17    }
18
19    @Recover
20    public String recover(IOException ex) {
21        return "fallback";
22    }
23}

This is the simplest solution and usually the right one. The values stay in configuration, while the service keeps the retry policy close to the method that needs it.

Enable Retry Support

The annotation will not do anything until retry support is enabled. In a Spring Boot application that normally means adding @EnableRetry on a configuration class.

1import org.springframework.boot.SpringApplication;
2import org.springframework.boot.autoconfigure.SpringBootApplication;
3import org.springframework.retry.annotation.EnableRetry;
4
5@EnableRetry
6@SpringBootApplication
7public class DemoApplication {
8    public static void main(String[] args) {
9        SpringApplication.run(DemoApplication.class, args);
10    }
11}

If you skip this step, the application starts normally, but no retries happen because the proxy that applies retry behavior is never created.

Use a Properties Bean for More Complex Policies

If several services share the same retry settings, bind the values once with @ConfigurationProperties and reference that bean from the annotation with SpEL. This keeps the configuration strongly typed and easier to test.

1import org.springframework.boot.context.properties.ConfigurationProperties;
2
3@ConfigurationProperties(prefix = "app.retry")
4public class RetrySettings {
5    private int maxAttempts;
6    private long delayMs;
7
8    public int getMaxAttempts() {
9        return maxAttempts;
10    }
11
12    public void setMaxAttempts(int maxAttempts) {
13        this.maxAttempts = maxAttempts;
14    }
15
16    public long getDelayMs() {
17        return delayMs;
18    }
19
20    public void setDelayMs(long delayMs) {
21        this.delayMs = delayMs;
22    }
23}

1@Retryable(
2    retryFor = IOException.class,
3    maxAttemptsExpression = "#{@retrySettings.maxAttempts}",
4    backoff = @Backoff(delayExpression = "#{@retrySettings.delayMs}")
5)
6public String fetchData() throws IOException {
7    throw new IOException("temporary failure");
8}

This form is useful when values need validation, reuse, or documentation beyond a single annotation.

Understand the Proxy Boundary

Spring Retry is proxy-based. That means the retry logic is applied when another bean calls the annotated method through the proxy. A call from one method to another method in the same class does not pass through the proxy, so retry will not trigger.

This matters more than the property injection itself, because many developers correctly configure maxAttemptsExpression and still see no retries due to self-invocation. If you need internal reuse, move the retried method to another bean or use a programmatic RetryTemplate.

Common Pitfalls

• Using maxAttempts instead of maxAttemptsExpression, which hardcodes the value and ignores configuration.
• Forgetting @EnableRetry, so the annotations are present but never applied.
• Calling the annotated method from the same class, which bypasses the Spring proxy and skips retry behavior.
• Typing the property key incorrectly, which causes placeholder resolution to fail at startup or use the wrong value.
• Expecting runtime config changes to update the annotation immediately, even though the proxy usually reads values during bean creation.

Summary

• Put retry numbers in configuration and reference them with expression attributes.
• Use maxAttemptsExpression and delayExpression rather than fixed annotation values.
• Enable retry support with @EnableRetry.
• Bind shared settings with @ConfigurationProperties when the policy is reused.
• Remember that Spring Retry depends on proxy-based method invocation, not direct self-calls.