Spring-framework: BeanCurrentlyInCreationException error depends on @ComponentScan basePackages values order [SPR-14307]

Created on 26 May 2016  路  13Comments  路  Source: spring-projects/spring-framework

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

team-attention core waiting-for-triage

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 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:

  • Shouldn't the bean processing from Spring be deterministic? If not how can we make it?
  • Could that be a timing issue? Should we expect differences across different hardware and OSes?
  • Is there a difference between running spring applications from a jar versus from the class files? I searched but I couldn't find any difference.

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. :(

All 13 comments

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:

  • Shouldn't the bean processing from Spring be deterministic? If not how can we make it?
  • Could that be a timing issue? Should we expect differences across different hardware and OSes?
  • Is there a difference between running spring applications from a jar versus from the class files? I searched but I couldn't find any difference.

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?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sbrannen picture sbrannen  路  4Comments

gurudatta11 picture gurudatta11  路  4Comments

Moomba42 picture Moomba42  路  3Comments

spring-projects-issues picture spring-projects-issues  路  5Comments

davidjgoss picture davidjgoss  路  4Comments