`BeanCurrentlyInCreationException` error depends on `@ComponentScan` `basePackages` values order [SPR-14307]

[spring-projects-issues]

István pató opened SPR-14307 and commented

spring-projects/spring-boot#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

[spring-projects-issues]

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.

[spring-projects-issues]

István pató commented

Thank you for answer!

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

[darssy]

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