Skip to content

Intermittent BeanCurrentlyInCreationException when using @Autowired on a FactoryBean or anywhere in its dependency graph [SPR-9255] #13893

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

Closed
spring-projects-issues opened this issue Mar 21, 2012 · 6 comments
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Mar 21, 2012

Andy Wilkinson opened SPR-9255 and commented

I've been bitten in the past by an intermittent BeanCurrentlyInCreationException when I've @Autowired a FactoryBean implementation. I believe that this is considered to be a no-no, but occassionally I forget and lose hours to diagnosing the problem until the penny drops. An example can be seen in https://issuetracker.springsource.com/browse/VMS-604. Today, I've been bitten by a variation of this same problem.

This time, rather than having an @Autowired FactoryBean I've got an @Autowired class that's a dependency of the FactoryBean. I believe this means that to avoid a possible BeanCurrentlyInCreationException I need to avoid using @Autowired on a FactoryBean and also on anything in the FactoryBean's dependency graph.

The main problem here is the intermittent nature of the failure. There appears to be something non-deterministic in the code that finds all of the candidates for a dependency. This, I'm guessing, is what makes the failure intermittent which, in turn, makes it harder to diagnose. I'm also wondering how Spring guarantees that there's only one possible candidate for the dependency if it, apparently, doesn't always need to initialise the FactoryBean to satisfy the dependency. Is there a risk that it might miss the fact that there are multiple candidates, or is there something about one ordering which means that it can successfully initialise the FactoryBean to check the type that it will produce without also triggering a BeanCurrentlyInCreationException?

Ideally, dependency resolution would be deterministic so that this problem happen none of the time or all of the time. Right now it's dangerous as the problem can be lurking for days or weeks until it occurs. If deterministic dependency resolution isn't possible, I'd love to see some improved diagnostics for this problem. Something that pointed out the dangerous use of @Autowired on a FactoryBean or one of its dependencies would be a big help.


Affects: 3.1 GA

Issue Links:

Referenced from: commits spring-attic/spring-framework-issues@6fa97fa, spring-attic/spring-framework-issues@189ba5b

2 votes, 4 watchers

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

Thanks, Andy. Of course, if you can provide a quick repo project that demonstrates the intermittent failure, it would really help to track this down. See https://github.com/SpringSource/spring-framework-issues#readme

@spring-projects-issues
Copy link
Collaborator Author

Andy Wilkinson commented

I've tried, but have failed thus far. I can easily produce the BeanCurrentlyInCreationException 100% of the time with an @Autowired FactoryBean but can't reproduce the intermittent failure in a simple test. I'll keep trying.

@spring-projects-issues
Copy link
Collaborator Author

Andy Wilkinson commented

I think the case where it fails 100% of the time may be more interesting than I'd thought. There's no circular dependency in the beans it tries to create, so it at least illustrates part of the problem. I'll submit a pull request.

I spent some time in the debugger looking through one of the far more complex cases that fails intermittently. As I said, I've been unable to reproduce that failure, but I thought that understanding why it doesn't fail might be informative. In a nutshell, when it succeeds it appears to be because the logic's short-circuited by a call to isSingletonCurrentlyInCreation from getSingletonFactoryBeanForTypeCheck on AbstractAutowireCapableBeanFactory. Perhaps of note is that getSingletonFactoryBeanForTypeCheck isn't called in the case where it fails 100% of the time.

@spring-projects-issues
Copy link
Collaborator Author

Andy Wilkinson commented

Pull request: spring-attic/spring-framework-issues#21

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Dec 5, 2013

Alexei Shpikat commented

This appeared to be a critical issue for us, as there exists no workaround for it.

Looks like a duplicate for #13346, and is also duplicated by #14983, so the problem seems to be quite wide-spread.

@spring-projects-issues spring-projects-issues added type: bug A general bug status: waiting-for-triage An issue we've not yet triaged or decided on and removed type: bug A general bug labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants