Due to legacy code, we’ve enabled circular dependencies. With the same codebase, both my colleague and I can run it normally on macOS, but on our server (Amazon Linux), we’re encountering circular dependency issues (Spring Boot 3.1.4). It’s been driving us crazy—we’ve run into this kind of problem at least three times. Our workaround has always been replacing constructor injection with @Autowired. What’s even more frustrating is that we haven’t been able to build a minimal reproducible case…
I did some research and found that many others have faced the same issue: https://stackoverflow.com/questions/29347723/why-does-spring-get-circular-dependency-issues-on-one-machine-and-not-another
I think this perspective might be accurate: https://stackoverflow.com/a/34206071/24228439
However, I haven’t found any related issues in the Spring Boot issuw tracker. I’d really like to know if anyone else has encountered something similar, and what solutions worked for them.
Comment From: bclozel
We should have plenty of issues like that in the Spring Boot and Spring Framework issue trackers.
Let me find a few here:
- https://github.com/spring-projects/spring-boot/issues/23222
- https://github.com/spring-projects/spring-boot/issues/27411
As for fixing such issues there are some workarounds like using "@Lazy" or ObjectProvider at the injection point:
- https://github.com/spring-projects/spring-boot/issues/41156#issuecomment-2180230477
- https://github.com/spring-projects/spring-boot/issues/36286
But the true recommendation is to refactor the code and break cycles for good. If you don't break cycles, you will always have to allow cycles in the first place and then rely on a best effort behavior that might break depending on external factors. After all, this is why we flipped the default for this in the first place: we acknowledge that fixing this in large codebases is challenging and this shouldn't happen in the first place.