In order to extend the RepositoryConfigurationDelegate, I would like to choose the ClassPathScanningCandidateComponentProvider implementation used by the multipleStoresDetected() method.
In an inherited ClassPathScanningCandidateComponentProvider, I would like to use the Vfs2PathMatchingResourcePatternResolver class (see this class on GitHub).
Overriding the multipleStoresDetected() could be a solution.
As explained in the SPR-12423, the ClassPathScanningCandidateComponentProvider allows to customize the ResourcePatternResolver implementation by calling the setResourceLoader method. SPR-12423
Affects: 1.9.1 (Evans SR1)
DATAJPA-631 ClasspathScanningPersistenceUnitPostProcessor should forward ResourceLoader configured to the ClassPathScanningCandidateComponentProvider used for the entity type scanning
Wouldn't it rather make sense to implement a custom ResourceLoader as this is the primary API that gets handed around to eventually be responsible for interaction around resource lookups. We already are set up to basically use the one that get's globally configured on the ApplicationContext, although multipleStoresDetected() currently doesn't set it on the CPSCCP (which would need to be fixed)
We now pip the Environment and ResourceLoader picked up from the infrastructure in the ClassPathScanningCandidateComponentProvider to detect multiple store modules. Global customize to the ResourceLoader should now be reflected in the detection as well