Regression in 4.1: UnsatisfiedDependencyException because a prototype-scoped FactoryBean is unexpectedly instantiated by getTypeForFactoryBean() [SPR-12786]

[spring-projects-issues]

Reid Harrison opened SPR-12786 and commented

Occurs after update to 4.1.4 from 4.0.4. More specifically, 4.0.9 to 4.1.0.

Please see https://github.com/reid-harrison/my-failing-bean for a sample project that reproduces the issue.

---

Affects: 4.1 GA, 4.1.5

Reference URL: http://stackoverflow.com/questions/28859716/prototype-scoped-spring-bean-incorrectly-created-at-context-creation-time-after

Issue Links:

• HttpInvokerProxyFactoryBean and co do not reliably expose correct type when declared via @Bean [SPR-11842] #16461 HttpInvokerProxyFactoryBean and co do not reliably expose correct type when declared via @Bean
• BeanFactory lacks method for getting bean by type with specified constructor arguments [SPR-11235] #15860 BeanFactory lacks method for getting bean by type with specified constructor arguments

Referenced from: commits 9b25d6a, f01a030

[spring-projects-issues]

Juergen Hoeller commented

This turns out to be a regression caused by #16461, where the algorithm doesn't stop at a declared FactoryBean<Object> (such as a plain JndiObjectFactoryBean) for @Bean methods anymore but rather tries to partially instantiate the target bean in such a case. I've addressed this through a catch block within getNonSingletonFactoryBeanForTypeCheck, ignoring a non-singleton candidate bean if we fail to instantiate it.

Note that I strongly recommend avoiding such declarations. A non-singleton FactoryBean is rather odd in general, but for any scope: Prefer a direct DataSource return type or whatever you retrieve from JNDI instead, using a JndiLocatorDelegate instead of a JndiObjectFactoryBean. If you insist on a FactoryBean, preferably declare a FactoryBean<DataSource> return type on your @Bean method instead of a plain FactoryBean implementation class.

Juergen