Istv谩n pat贸 opened SPR-14307 and commented
https://github.com/spring-projects/spring-boot/issues/6045
We have an issue with 'circular reference' error. When I started my Spring Boot app on my Ubuntu 16.04 desktop OS, the issue is not showing up. If I running the app on the Ubuntu 16.10 Server OS, then I get an error:
_Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'exampleService': Requested bean is currently in creation: Is there an unresolvable circular reference?_
If I change
@ComponentScan(basePackages = "org.springframework.boot.issues.ghXXXX")
to
@ComponentScan(basePackages = {"org.springframework.boot.issues.ghXXXX.server", "org.springframework.boot.issues.ghXXXX.service", "org.springframework.boot.issues.ghXXXX"})
then I don't get BeanCurrentlyInCreationException on Ubuntu 16.10 Server OS.
I can reproduce the issue with a maven project. The code is failing on same OS, if I change @ComponentScan basePackages order.
Affects: 4.2.6
Reference URL: https://github.com/patoi/spring-boot-issues/tree/gh-6045/gh-6045
3 votes, 6 watchers
Juergen Hoeller commented
This is probably not related to the component scan order per se but rather to the initialization order of the beans contained in your packages: When ".server" gets picked up first, the beans in that package will get registered first and therefore initialized first, with a potential circular reference approached from that angle. Circular references are not cleanly resolvable from any side; depending on FactoryBean setups or other indirections, they may fail from one end but not from the other. In that sense, the behavior that you're seeing is unfortunate but within our expectations for such an arrangement.
I'd rather get rid of the circular reference altogether. If that's not feasible, you could mark one or both dependency declarations as @Lazy, allowing the container to postpone the initialization to their first actual use: This usually makes circular reference issues go away, since such circles are only really a problem if both ends of the dependency insist on getting a fully initialized other...
Alternatively, a depends-on / @DependsOn declaration on your ".service" bean, pointing to the ".server" bean, expresses an explicit initialization order independent from the registration order. This would allow for always initializating your circular dependency from the same end, without any @Lazy markers involved.
Istv谩n pat贸 commented
Thank you for answer!
Bulk closing outdated, unresolved issues. Please, reopen if still relevant.
I'm afraid that this is still a reality.
I had that problem and I was fighting with it for the past 3 days. In my case it was something more weird. I was developing and running from IntelliJ. Everything was fine there. When I deployed the software to another machine resembling the production environment, I got a circular dependency error. After lots of trial and error I realized what the difference was: intelliJ relies on the class files to run the application. We were making a jar. After I set IntelliJ to create a jar and run the jar on my machine I got the same error.
I was able to fix it with the workaround mentioned here. There is still the concern though why this thing happens. I enabled debugging for spring, and I saw that the Eagerly caching bean 'XYZ' to allow for resolving potential circular references messages were not appearing with the same order (comparing the classes vs jar execution). I also saw 45 less messages (compared to 144 that I was expecting to see). Again the only difference is the classes vs jar. The code is the same. This puzzles me as there shouldn't(?) be any differences between the 2 execution methods.
So the questions are:
I am at your disposal to provide any additional information as my team is very keen on having that resolved. The "random" manner of bean processing makes neither my teammates nor our managers confident. :(
I was able to fix it with the workaround mentioned here.
Those are suggestions to improve the configuration to eliminate ambiguity, not workarounds.
@rstoyanchev No disrespect: is this the only thing that stroke you odd? How about the randomness of processing the beans? And when I run the same application from IntelliJ there doesn't seem to be any _ambiguity_, everything there is crystal clear to spring...
No offense taken. It's just that you've asked to re-open an old ticket that has the same Exception, but likely comes from very different context and maybe a different problem.
OK then. If you want me to create a new ticked I will do so. I saw it being bulk closed with the note:
Bulk closing outdated, unresolved issues. Please, reopen if still relevant.
Emphasis is mine. I thought that it is unresolved and as such I is subject to reopening.
but likely comes from very different context and maybe a different problem.
Perhaps, perhaps not. That's why the issue is unresolved... All references to "occasional circular dependencies" were leading me to this issue. In any case if you think that it's better, I will be happy to create a new issue and copy all the information there.
Agreed with @adamstyl, this is very annoying, when circular dependencies error occurs randomly only on CI/CD stand.
Still happening, 2.1.4.RELEASE.
Temporary crutch solution: ENV spring.main.lazy-initialization=true
@adamstyl there is a same case as you. When i run my spring project in DEV/QA environment or just run it in local side ( all of them run in wildfly server - that is Jboss) , ok there is no any probelm.
But if i run it in docker container for wildfly, there are a lot of circle dependences error messages pop up..
Temporary crutch solution:
ENV spring.main.lazy-initialization=true
@Arsennikum thx for u adding, but if i want to add this to normal spring project (not spring-boot), what can i do for this?
BTW, which spring version can be supported?
Most helpful comment
I'm afraid that this is still a reality.
I had that problem and I was fighting with it for the past 3 days. In my case it was something more weird. I was developing and running from IntelliJ. Everything was fine there. When I deployed the software to another machine resembling the production environment, I got a circular dependency error. After lots of trial and error I realized what the difference was: intelliJ relies on the class files to run the application. We were making a jar. After I set IntelliJ to create a jar and run the jar on my machine I got the same error.
I was able to fix it with the workaround mentioned here. There is still the concern though why this thing happens. I enabled debugging for spring, and I saw that the
Eagerly caching bean 'XYZ' to allow for resolving potential circular referencesmessages were not appearing with the same order (comparing the classes vs jar execution). I also saw 45 less messages (compared to 144 that I was expecting to see). Again the only difference is the classes vs jar. The code is the same. This puzzles me as there shouldn't(?) be any differences between the 2 execution methods.So the questions are:
I am at your disposal to provide any additional information as my team is very keen on having that resolved. The "random" manner of bean processing makes neither my teammates nor our managers confident. :(