Skip to content

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

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 Jun 18, 2015 · 4 comments
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 18, 2015

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:

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

Phil Webb commented

#821

@spring-projects-issues
Copy link
Collaborator Author

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
Copy link
Collaborator Author

spring-projects-issues commented Jul 14, 2015

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

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement and removed type: enhancement A general enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on status: ideal-for-contribution An issue that a contributor can help us with type: enhancement A general enhancement labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants