-
Notifications
You must be signed in to change notification settings - Fork 38.5k
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
Comments
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 |
Andy Wilkinson commented I've tried, but have failed thus far. I can easily produce the |
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 |
Andy Wilkinson commented Pull request: spring-attic/spring-framework-issues#21 |
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. |
Bulk closing outdated, unresolved issues. Please, reopen if still relevant. |
Andy Wilkinson opened SPR-9255 and commented
I've been bitten in the past by an intermittent
BeanCurrentlyInCreationException
when I've@Autowired
aFactoryBean
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 theFactoryBean
. I believe this means that to avoid a possibleBeanCurrentlyInCreationException
I need to avoid using@Autowired
on aFactoryBean
and also on anything in theFactoryBean
'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 theFactoryBean
to check the type that it will produce without also triggering aBeanCurrentlyInCreationException
?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 aFactoryBean
or one of its dependencies would be a big help.Affects: 3.1 GA
Issue Links:
@Autowired
properties not reliably set in FactoryBean before getObject ("duplicates")Referenced from: commits spring-attic/spring-framework-issues@6fa97fa, spring-attic/spring-framework-issues@189ba5b
2 votes, 4 watchers
The text was updated successfully, but these errors were encountered: