Use already loaded metadata when possible for AbstractAutowireCapableBeanFactory.getTypeForFactoryMethod [SPR-13144]

[spring-projects-issues]

Phil Webb opened SPR-13144 and commented

The AbstractAutowireCapableBeanFactory.getTypeForFactoryMethod() is called frequently when a typical Spring Boot application starts and tends to show up often when profiling applications.

The majority of the calls are resolving @Configuration @Bean methods and since Spring 4.2 now surfaces getReturnTypeName() in MethodMetadata we could use this information rather than needing to iterate all methods in the class.

---

Issue Links:

• Reduce BeanDefinition cloning in AbstractBeanFactory.getMergedBeanDefinition [SPR-12236] #16851 Reduce BeanDefinition cloning in AbstractBeanFactory.getMergedBeanDefinition

0 votes, 5 watchers

[spring-projects-issues]

Phil Webb commented

#821

[spring-projects-issues]

Phil Webb commented

This patch really needs #821 to be applied to be really useful.

I'd have preferred to use RootBeanDefinition.resolvedFactoryMethodReturnType to store the resolved return type but this breaks several tests. The main problem is that GenericTypeAwareAutowireCandidateResolver.getReturnTypeForFactoryMethod relies on resolvedFactoryMethodReturnType being null in order to use the method ResolvableType. I tried switching this logic around but that breaks other resolver tests.

[spring-projects-issues]

Juergen Hoeller commented

I'm putting this one back into triage state, since the recent changes for #16851 might do the job already. With such early caching of merged bean definitions, it might be feasible to stick with the regular factory method resolution algorithm (and the existing caching of resolved types in the merged bean definition) instead of adding an extra code path. After all, factory method type resolution is rather involved in corner cases such as overloaded factory methods which may even appear with @Bean declarations (even if discouraged, we do support it).

Juergen