Skip to content
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

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

Closed
spring-issuemaster opened this issue Mar 4, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Mar 4, 2015

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:

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

Referenced from: commits 9b25d6a, f01a030

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 5, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.