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

getBeanNamesForType(ResolvableType) doesn't work for raw singleton instance from @Bean method with generic return type [SPR-17524] #22056

spring-projects-issues opened this issue Nov 21, 2018 · 1 comment
in: core status: backported type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Nov 21, 2018

Konstantin opened SPR-17524 and commented

When calling beanFactory.getBeanNamesForType with  ResolvableType.forClassWithGenerics(), if bean is lazy it works, after initialization or bean not lazy this code will not work. 

Here's a case, all asserts return true:

public class DemoApplication \{
 public static void main(String[] args) {
 ConfigurableApplicationContext run =, args);
 assert run.getBeanNamesForType(ResolvableType.forClassWithGenerics(Test.class, String.class)).length == 0; 
 assert run.getBean(run.getBeanNamesForType(ResolvableType.forClassWithGenerics(Test.class, Integer.class))[0]) != null;
 assert run.getBeanNamesForType(ResolvableType.forClassWithGenerics(Test.class, Integer.class)).length == 0; } 

Test<String> getString() \{ 
return new Test<>(); 

Test<Integer> getInteger() \{ 
return new Test<>();
 } }

 class Test<T>\{ }

Affects: 5.1.2

Issue Links:

  • #18669 getBeanNamesForType(ResolvableType) does not reliably work for beans with AOP proxies
  • #19578 getBeanNamesForType(ResolvableType) doesn't match generic factory method return type for yet-to-be-created bean

Referenced from: pull request #2027, and commits ebbe14c, e9f7c35, 7b2eebe

Backported to: 5.0.11, 4.3.21

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 25, 2018

Juergen Hoeller commented

I've resolved this in a slightly different way, aligned with the earlier revision behind #19578, adding all remaining cases to its set of tests. Thanks for raising this! Good timing as well since we're about to release Spring Framework 5.1.3, 5.0.11 and 4.3.21 tomorrow...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core status: backported type: bug
None yet

No branches or pull requests

2 participants