Skip to content

getBeanNamesForType should consider FactoryBean generics for early introspection of config classes as well [SPR-11480] #16105

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

Closed
spring-projects-issues opened this issue Feb 24, 2014 · 4 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: superseded An issue that has been superseded by another type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Feb 24, 2014

Phil Webb opened SPR-11480 and commented

Spring Boot was recently updated to consider FactoryBean generics. This could be ported into BeanFactoryUtils if useful.

See spring-projects/spring-boot#355 & spring-projects/spring-boot@5d591ed


Affects: 4.0.2

Issue Links:

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Aren't we talking about ListableBeanFactory's getBeansOfType here? BeanFactoryUtils only really contains an algorithm for accumulation over a factory hierarchy...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Phil Webb commented

Right, my mistake. We call BeanFactoryUtils, but the enhancement should be in the ListableBeanFactory implementation. I have updated the description.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

To the best of my attempts to reproduce this, it all works fine after context refresh. So I suppose we're only really talking about introspection of factory method return types before the containing Class has been resolved? This is an assumption in the current getTypeForFactoryBean algorithm, after all: It only starts looking at factory method return type signatures for bean definitions with the bean class name already resolved to a Class...

Juergen

@jhoeller
Copy link
Contributor

jhoeller commented Jan 3, 2024

Closing this in favor of the more general #18558. Optimized FactoryBean resolution is still a topic to be investigated but I don't see any specific action we can take for this ticket here.

@jhoeller jhoeller closed this as not planned Won't fix, can't repro, duplicate, stale Jan 3, 2024
@jhoeller jhoeller added the status: superseded An issue that has been superseded by another label Jan 3, 2024
@jhoeller jhoeller removed this from the 6.x Backlog milestone Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: superseded An issue that has been superseded by another type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants