@Inject Autowiring by type fails on FactoryBeans and injected refs the FactoryBean depends on [SPR-7450]

[spring-projects-issues]

Keith Donald opened SPR-7450 and commented

Ran into a rather odd problem. Testing against latest 3.0.4 nightly build.

The following fails with a no default constructor found exception:

<beans:bean id="badgeSystem" class="com.springsource.greenhouse.badge.BadgeSystemFactoryBean"/>
	
<beans:bean id="badgeRepository" class="com.springsource.greenhouse.badge.JdbcBadgeRepository"/>

The following works:

<beans:bean id="badgeSystem" class="com.springsource.greenhouse.badge.BadgeSystemFactoryBean">
	<beans:constructor-arg ref="badgeRepository" />
</beans:bean>
	
<beans:bean id="badgeRepository" class="com.springsource.greenhouse.badge.JdbcBadgeRepository">
	<beans:constructor-arg ref="jdbcTemplate" />
</beans:bean>

The injection points:

@Inject
public BadgeSystemFactoryBean(BadgeRepository badgeRepository) {
	this.badgeRepository = badgeRepository;
}


@Inject
public JdbcBadgeRepository(JdbcTemplate jdbcTemplate) {
	this.jdbcTemplate = jdbcTemplate;
}

context:annotation-config is turned on.

Strangely, removing the FactoryBean and leaving just the Repository def relying on byType autowiring works:

<beans:bean id="badgeRepository" class="com.springsource.greenhouse.badge.JdbcBadgeRepository" />

Is there something special related to FactoryBean autowiring I'm missing?

---

Affects: 3.0.3

Issue Links:

• Document BeanFactoryPostProcessor implementation constraints [SPR-7466] #12124 Document BeanFactoryPostProcessor implementation constraints ("is superseded by")

[spring-projects-issues]

Chris Beams commented

Nothing jumps right out. Any chance you could submit a failing test case?

[spring-projects-issues]

Chris Beams commented

Looks like this is not a bug with Spring, at least not in any direct way. It's an issue coming from the Spring Security OAuth namespace. To prove this, do the following:

1. check out greenhouse from source (I'm at commit b1b53e6ebd269168df139794f8dd47733ce8f6ff)
2. add email.properties and s3.properties as described on the wiki
3. import into eclipse and deploy
4. notice that everything deploys without error
5. edit integration-activity.xml and comment out the <constructor-arg/> elements for the badgeSystem bean
6. deploy once again
7. notice the failure at deployment time that BadgeSystemFactoryBean.init() cannot be found
8. edit security-oauth-provider.xml and comment out just the <oauth:provider/> element.
9. deploy once again
10. notice that deployment succeeds without error.

So what's going on here? One way or another the processing of the provider element is disabling annotation-config behavior. I checked out the spring-security-oauth project and spent some time digging around in the OAuthProviderBeanDefinitionParser, but found nothing suspicious-looking.

At any rate, it appears reasonable to assume that this is bad behavior on the OAuth end of things. I would suggest getting in touch with them, or digging into the issue further for yourself. Maybe Luke could help.

As for Spring and specifically 3.0.4, I have no reason to believe this merits continued bug status, so resolving as Invalid.

Hope this helps.

[spring-projects-issues]

Chris Beams commented

This issue was ultimately a result of a badly-behaved BeanFactoryPostProcessor (Spring Security OAuth's OAuthTokenLifecycleRegistryPostProcessor) prematurely instantiating bean instances (e.g.: the factory bean in question), such that the regular container lifecycle was short circuited. In this case, AutowiredBeanPostProcessor never had the opportunity to be applied against the FactoryBean, thus the failure to respect @Inject metadata.

Rather than a bug, this is a documentation issue, and #12124 addresses that.