@Autowired dependencies against bean definitions with type-inspecific factory-methods may fail [SPR-8769]

[spring-projects-issues]

David Turanski opened SPR-8769 and commented

Autowire Mock Object using factory-method fails with NoSuchBeanDefinitionException if the Autowired bean comes after the dependent.

---

Issue Links:

• Introduce FactoryBean to create mock beans with EasyMock [SPR-9130] #13769 Introduce FactoryBean to create mock beans with EasyMock
• Infer return type of parameterized static factory methods [SPR-9493] #14127 Infer return type of parameterized static factory methods ("is superseded by")

Referenced from: commits spring-attic/spring-framework-issues@b38d68c, spring-attic/spring-framework-issues@b742560, spring-attic/spring-framework-issues@bfbeccc

[spring-projects-issues]

Chris Beams commented

Hi David,

Could you provide a bit more context here? A code snippet would do.

[spring-projects-issues]

David Turanski commented

spring-attic/spring-framework-issues#8

[spring-projects-issues]

Chris Beams commented

Thanks, I'll take a look at it. Btw, we'll get pull requests integrated into JIRA in a little more formal way soon enough. In the meantime it's a good idea to at least mention them here via a comment after submission on github.

[spring-projects-issues]

Chris Beams commented

Hi David,

First, thanks for the detailed repro project. It made it very easy to analyze the problem.

This is a genuine issue, however I'm marking it as won't fix for pragmatic reasons. Let me explain why it's occurring:

When you declare the following bean definition

<bean class="org.easymock.EasyMock" factory-method="createMock" >
    <constructor-arg value="dturanski.autowire.bug.Foo"/>
</bean>

there is no way the Spring container can infer the type of the resulting mock object without actually initializing the bean, i.e. calling the createMock init-method.

Your Bar bean is using @Autowired to recieve it's Foo dependency. In the failure case, the Bar is declared before the EasyMock bean. Parsing (a.k.a bean definition reading) happens in a top-down fashion, meaning that the Bar bean is parsed and registered with the container first, then the EasyMock bean. Bean initialization occurs in the same order as bean registration, which means that as Bar is being initialized (first), it gets passed through the AutowiredAnnotationBeanPostProcessor which detects the @Autowired annotation and looks for available candidates. Because the EasyMock bean has not yet been initialized (and thus the container does not yet know that it will ultimately result in a bean of type Foo), the AABPP throws the exception that you see - that there is no such bean of type Foo available.

This explains, then, why reversing the order makes everything work. The EasyMock bean is initialized and registered against the container first, and the container then has awareness of a single bean of type Foo. By the time AABPP gets to Bar, autowiring Foo works as expected.

So, why then is this being resolved "Won't Fix"?

1. it's already an edge case. One must be dealing with a bean definition based on a factory-method that returns Object or some other too-general type, AND the product of that bean must be expected as an @Autowired target for some other bean, AND these beans must be declared in the wrong order. As you've proven, this is not 100% impossible to encounter in practice, but indeed unlikely.
2. reasonable workarounds exist. You demonstrated one in AutoWireMockTest-context-factory-init-works.xml: create a custom factory. Your FooFactory gets the job done, because its init() factory-method returns the target type Foo as opposed to Object. Autowire-candidate inference has no problem discovering this, because it can be discovered up front prior to bean initialization. Instead of creating a custom factory type, you can also simply declare the EasyMock bean as a @Bean method and declare the return type of that method accordingly. This is the recommended solution to your problem, btw.
3. most importantly, any cure would likely be worse than the disease. Let's explore the options for 'fixing' this problem below.

We could introduce a more aggressive approach to 'inferring' factory-method return types by eagerly initializing bean definitions with factory-method attributes when necessary. But what constitutes 'necessary'? Is it when the factory-method returns Object? That could theoretically be a valid @Autowired target type (though very unlikely). Even if one instituted a policy of eager initialization for Object-returning factory-methods, this would not necessarily be sufficient either. It could be that a factory-method returns Service for example, but you have an @Autowired injection point that needs FooService, which is assignable to Service. You would end up with the same result of "no beans of type FooService found". Therefore, to provide a complete solution, one would need to eagerly initialize any and all beans with factory-method attributes! This 'solution' gets complicated by the fact that these beans themselves may have dependencies on other beans, which can get into circular dependency issues and other problems that will emerge because of the 'early' or 'premature' nature of the initialization. I can foresee some of these issues, but what's more important is that I know I cannot foresee all of them. Any such solution will almost certainly create unintended side effects, i.e. more severe bugs.

Another possible solution would be to introduce a 'hint' in the <bean> element that gives the container a clue about the return type of the factory-method. It would look something like this:

<bean class="org.easymock.EasyMock" factory-method="createMock" type="Foo">
    <constructor-arg value="dturanski.autowire.bug.Foo"/>
</bean>

The problems with this approach are several:

• type only makes sense in combination with factory-method, and only for this edge case.
• it would create confusion with relation to the existing class attribute
• it is only applicable in situations where the type can be known up front. If there is any variability in the type that the factory-method may return, you're out of luck (though that is admittedly unlikely)

We've always been pretty conservative about adding anything to the core beans namespace, so given the low likelihood of encountering this issue in the first place, it's not a good candidate.

Another possible solution to this problem would be to group together beans having factory-method attributes and initialize them first, followed by all 'regular' bean definitions. The problem with that solution is, again, that any such fundamental change to the way the container works is highly likely to cause side effects and so just shouldn't be done unless critical. This also doesn't make sense in theory, because there's nothing saying that beans with factory-methods don't have @Autowired dependencies themselves that would suffer from the same order-dependent issue. It's just further pushing the problem out to the edge, not really 'solving' it.

I hope this helps make sense of the issue, as well as why there's probably nothing to do about it.

Cheers,

Chris

[spring-projects-issues]

Sam Brannen commented

FYI: if you're watching this issue you may also be interested in watching #14127.

Sam