Hey there, let's break down how to fix this startup failure you're facing. The root cause here is that Spring Boot 2.6.0 disabled automatic circular reference resolution by default—a change that turns previously hidden circular dependencies into hard startup errors, which is exactly what's happening with your securityConfig bean.

Here are actionable solutions to resolve this:

1. Quick Fix: Re-enable Circular References (Temporary) #

If you need to get your app up and running immediately while you work on a proper fix, you can explicitly allow circular references in your configuration:

For application.properties: #

spring.main.allow-circular-references=true

For application.yml: #

spring:
  main:
    allow-circular-references: true

Note: This is a short-term workaround. It's better to eliminate the circular dependency long-term to keep your codebase clean and maintainable.

2. Best Practice: Refactor Code to Eliminate the Circular Dependency #

This is the recommended approach. Let's look at common scenarios and fixes:

a. Use @Lazy to Delay Initialization #

If one of the beans in the cycle doesn't need to be initialized immediately, add the @Lazy annotation to its injection point. For example, if SecurityConfig depends on UserService which also depends on SecurityConfig:

@Configuration
public class SecurityConfig {
    private final UserService userService;

    // Inject UserService lazily to break the cycle
    public SecurityConfig(@Lazy UserService userService) {
        this.userService = userService;
    }
}

b. Switch to Setter Injection Instead of Constructor Injection #

Constructor injection requires all dependencies to be available at bean creation time, which can trigger circular errors. Setter injection happens after the bean is created, often breaking the cycle:

@Configuration
public class SecurityConfig {
    private UserService userService;

    @Autowired
    public void setUserService(UserService userService) {
        this.userService = userService;
    }
}

c. Extract Shared Logic to a Separate Bean #

If both securityConfig and another bean depend on shared functionality, pull that logic into a standalone component. For example, if both rely on a permission-checking utility:

@Component
public class PermissionUtils {
    // Shared permission logic here
}

Then inject PermissionUtils into both SecurityConfig and the dependent bean, removing the direct dependency between them.

d. Remove Unnecessary Dependencies #

Double-check if securityConfig really needs the bean it's referencing, or vice versa. Sometimes circular dependencies creep in when we inject full beans when only a small part of their functionality is needed.

Why This Happened After the Upgrade #

Prior to Spring Boot 2.6.0, the framework automatically handled many circular references behind the scenes. The team disabled this by default to encourage cleaner code practices and reduce potential initialization issues that circular dependencies can introduce.

内容的提问来源于stack exchange，提问作者Thirumal