The ClassPathScanningCandidateComponentProvider is used by Spring Data in such a way that it could in principle take advantage of the spring.components index, but in practice it does not. The problem is that Spring Data is looking for components that match a name, and there is no special purpose include filter for that, so it ends up using a regex matcher that always matches (which is wasteful and cannot be applied to the indexed components).
One solution would be to provide a special AlwaysMatchesFilter that could be applied in Spring Data and include it in the indexSupportsIncludeFilter() test. Another would be to simply treat the case of no filters as meaning by convention "include all".
The text was updated successfully, but these errors were encountered:
I think I vaguely remember that use case. The reason why I ignored it at the time is that it seems that scan expects also classes that are not flagged with a particular annotation.
If the class is not somehow annotated with @Index it will not end up in the index. If it's not there, an always filter will not match it obviously. Did I read that wrong? Perhaps you could link to the code that Spring Data uses?
I get what you mean about the always filter. AFAIK there is no explicit @Index annotation anywhere, but the Spring Data components (and entities) end up in the index just fine. The problem is that they can't be located using the component scanner index. The code is in CustomRepositoryImplementationDetector.findCandidateBeanDefinitions() in Spring Data Commons. It needs to locate a class with a specific name in a sub-package of a given base path.
I don't see a use case for the "all" case as the index won't contain a component unless it's been flagged with @Indexed directly or indirectly. Currently, the use case you've described search by name classes that aren't annotated at all so those can't be in the index.