-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Consider generics when predicting FactoryBean types #23338
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
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Milestone
Comments
6 tasks
philwebb
added a commit
to philwebb/spring-framework
that referenced
this issue
Jul 23, 2019
Update the `FactoryBean` type prediction logic (primarily in the `DefaultListableBeanFactory`) so that generic type information is considered when calling `getBeanNamesForType` on a non-frozen configuration. Calling `getBeanNamesForType` with `allowEagerInit` disabled will now detect `FactoryBean` variants as long as generic type information is available in either the class or the factory method return type. Closes spring-projectsgh-23338
philwebb
added a commit
to philwebb/spring-framework
that referenced
this issue
Jul 23, 2019
Update `getTypeForFactoryBean` detection so that a bean definition attribute can be used to supply the result. This commit allows projects such as Spring Data to provide the result that would be supplied by `getObjectType` early so that we don't need to initialize the `FactoryBean` unnecessarily. Closes spring-projectsgh-23338
jhoeller
pushed a commit
that referenced
this issue
Jul 31, 2019
Update `getTypeForFactoryBean` detection so that a bean definition attribute can be used to supply the result. This commit allows projects such as Spring Data to provide the result that would be supplied by `getObjectType` early so that we don't need to initialize the `FactoryBean` unnecessarily. Closes gh-23338
philwebb
added a commit
to philwebb/spring-framework
that referenced
this issue
Jul 31, 2019
Update `AbstractAutowireCapableBeanFactory.getTypeForFactoryBean` to use fallback to `determineTargetType` if the factory bean definition does not have a resolved class. This is required for the case where a `@Configuration` class is picked up via component scanning and has a bean type that has not yet been resolved. Closes spring-projectsgh-23338
I found an annoying edge case that means any I think I have a fix in this branch |
Resolving a |
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)
type: enhancement
A general enhancement
It would be beneficial if we could consider generics when trying to predict the result of
FactoryBean.getObjectType()
. We currently have difficulty withgetBeanNamesForType
if the bean being considered is a factory bean and we don't want to initialize it early.It's possible that we can still deduce the type using generics of the factory method, or the class itself. For example:
We have logic to do this already as part of
DefaultListableBeanFactory.getTypeForFactoryBean
, however, in its current form that method may also cause early initialization of the bean.The text was updated successfully, but these errors were encountered: