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

Closed
spring-issuemaster opened this Issue Nov 21, 2018 · 1 comment

Comments

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

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:

@SpringBootApplication 
public class DemoApplication \{
 public static void main(String[] args) {
 ConfigurableApplicationContext run = SpringApplication.run(DemoApplication.class, 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; } 

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

@Bean 
@Lazy 
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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

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
You can’t perform that action at this time.