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

Cache ASM metadata at the context level [SPR-14654] #19219

spring-issuemaster opened this Issue Sep 1, 2016 · 1 comment


None yet
2 participants
Copy link

spring-issuemaster commented Sep 1, 2016

Stéphane Nicoll opened SPR-14654 and commented

While working on #16509 I noticed that caching several ClassPathScanningCandidateComponentProvider instances are instantiated when the application context is refreshed. With Spring Boot in particular, those instances are working on the same base package(s) with different filters.

In the end we scan the same Resources, load the same meta-data and figure out based on that if we have to include the component.

It would be much nicer if that information was cached for the duration of the refresh. Also, creating a valid ClassPathScanningCandidateComponentProvider requires you to pass the Environment and the ResourceLoader. Both of those are available from ApplicationContext. Perhaps the latter could take care of providing a shared instance or something?

Affects: 5.0 M1

Issue Links:

  • #16509 Spring-specific index file for component candidate classes
  • #19844 Allow for CachingMetadataReaderFactory cache size to be easily updated
  • #19248 ConfigurationClassParser does not use ApplicationContext's ResourceLoader for its MetadataReaderFactory
  • #19627 Backport streamlined ClassPathBeanDefinitionScanner setup

Referenced from: commits 7818c65


This comment has been minimized.

Copy link

spring-issuemaster commented Dec 27, 2016

Juergen Hoeller commented

I've introduced a general resource cache facility in DefaultResourceLoader which CachingMetadataReaderFactory automatically uses now when provided with an ApplicationContext as ResourceLoader (since all of our context implementations extend DefaultResourceLoader already). Any such caches get reused in an unbounded fashion up until AbstractApplicationContext's finish-refresh phase and automatically cleared then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment