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

Consider generics when predicting FactoryBean types #23338

Closed
philwebb opened this issue Jul 23, 2019 · 2 comments
Closed

Consider generics when predicting FactoryBean types #23338

philwebb opened this issue Jul 23, 2019 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@philwebb
Copy link
Member

It would be beneficial if we could consider generics when trying to predict the result of FactoryBean.getObjectType(). We currently have difficulty with getBeanNamesForType 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:

@Bean
public FactoryBean<MyBean> myBean() {
    ...
}
public class MyFactoryBean implements FactoryBean<MyBean> {
    ...
}

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.

@philwebb philwebb self-assigned this Jul 23, 2019
@philwebb philwebb added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement labels Jul 23, 2019
@philwebb philwebb added this to the 5.2 RC1 milestone Jul 23, 2019
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 philwebb reopened this Jul 31, 2019
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
@philwebb
Copy link
Member Author

I found an annoying edge case that means any @Configuration class picked up by component scanning won't be detected correctly. This is because the bean definition has a String type not a Class type and hasBeanClass() return false.

I think I have a fix in this branch

@jhoeller
Copy link
Contributor

jhoeller commented Jul 31, 2019

Resolving a FactoryBean class along the lines of that branch looks ok to me...

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
Projects
None yet
Development

No branches or pull requests

2 participants