-
Notifications
You must be signed in to change notification settings - Fork 38k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BeanCurrentlyInCreationException
error depends on @ComponentScan
basePackages
values order [SPR-14307]
#18879
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 I'd rather get rid of the circular reference altogether. If that's not feasible, you could mark one or both dependency declarations as Alternatively, a |
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 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. :( |
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:
Emphasis is mine. I thought that it is unresolved and as such I is subject to reopening.
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: |
@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.. |
@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? |
Now this happened to me. I thought I was smart when I tried to decorate a bean for tests like this: /** the actual class used for prod */
@Service
public class ActualService {
// ...
}
// then in tests:
@Configuration
@ComponentScan(basePackages = {"com.company.package.blabla"})
@Import(ProdConfiguration.class)
public class TestConfiguration {
@Primary // override the default ActualService bean
@Bean
public ActualService fakeActualService(@Named("actualService") ActualService actualService) {
ActualService spy = Mockito.spy(actualService);
// do stuff with spy...
return spy;
}
} the intent, for the particular test package, is to take the actual implementation and stub out some methods with fakes. Is this a bad design? Yes, welcome to legacy codebases. Please do not suggest how to fix this in an OO-friendly way, I know that and will do the refactoring as soon as possible. That said, this works on Windows. It does not on Linux, with either I understand my idea is probably wrong and only works by accident, but that's the point - if it works locally I totally expect it to work on CI (or colleagues' machines), too. Please make this deterministic. I do not really care which way - either fail all the time or make this work all the time. Even failing in some cases while working in others, when being consistent across environments, would be a better solution than this... :( |
We have what could be a similar issue that we only encountered when building a replacement Jenkins server. When we build the application with our old Jenkins server (running on Amazon Linux), running the application (using When we build exactly the same code, with the new Jenkins server (running on Ubuntu Server), which uses the same JDK and Maven versions, running the application fails (on every OS we've tried) with the following error:
We've done a diff of the two JAR files, the only differences we found were timestamps in the MANIFEST files. |
@autowire also has this problem. P.S @lazy annotation allows it to run but have some disadvantages. |
Got same issue here,same code, jar packaged in one of our jenkins server throws : |
I had the same problem, basically the same situation as described by others. This circular dependency problem occurs only for |
I used the |
Hello all, working on the same problem in a project with Spring, K8s on Azure platform, where we tried two alternatives:
|
I also encountered the same problem. In order to find the final cause, I traced the source code of springboot. I am glad that I finally found the root cause of the problem. The reason is that the order of instantiation of springboot beans is related to the order of the list of files returned from the jar package. The different platforms of the jar package lead to different order of the file list returned by jarFile.entries(). For specific logic, please see org.springframework.core.io.support.PathMatchingResourcePatternResolver#doFindPathMatchingJarResources (I am using springboot version 1.5.13). To solve this problem, it is necessary to do a natural sorting to solve the problem of inconsistent behavior of the same code in different environments. in chinese: |
Great Job 👍 in chinese: 666 |
Great find. Although I'm not working on spring anymore, I think that the way to go (if anyone would be interested to fix this of course) would be first to process the source files and then try to create the object graph. That way |
Hello @liangjihua, all Is there an example of how I can do this? Also, last but not least, I would assume that eventually @lazy is not at all an acceptable solution for this? or better say even with the use of @lazy we may come across the same issue? thanks in advance. |
Hi, org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'XXX': Requested bean is currently in creation: Is there an unresolvable circular reference? |
Ohh my goodness, this is for real ? well I was recently started facing this issue, everything works on my local but AWS it started giving this error. After reading the above reply, I changed my filename to start something with "Z" so it goes in the end. |
BeanCurrentlyInCreationException
error depends on @ComponentScan
basePackages
values order [SPR-14307]
The randomness that affects you is a consequence of the context trying to do its best with what's being requested. If you use circular references, then you can be affected from what seems to be unrelated (such as adding a feature that creates a proxy that leads to the early cache to not get the aspect applied). I understand that it can be problematic if you don't know about the cycle and you just realize at the wrong possible time because an environment change makes it fail. We've been improving bits and pieces in that area recently. Given how old this issue is, can someone please share a sample that exhibits the issue at hand (i.e. the difference of behavior for a change in base packages order). The original sample with a supported version fails consistently for me. |
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed. |
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue. |
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
to
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
The text was updated successfully, but these errors were encountered: