Support module path scanning for "classpath*:" resource prefix #28506
Assignees
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
in: test
Issues in the test module
type: enhancement
A general enhancement
Milestone
Comments
sbrannen
added
in: core
This was referenced May 23, 2022
sbrannen
added a commit
to sbrannen/spring-framework
that referenced
this issue
May 23, 2022
Prior to this commit, searching for classpath resources using the "classpath*:" resource prefix did not find all applicable resources for applications deployed as modules -- for example, when test classes and resources are patched into the application module automatically by Maven Surefire. This affected component scanning -- for example, via [@]ComponentScan -- and PathMatchingResourcePatternResolver.getResources(String) in general. This commit addresses this by introducing first-class support for scanning the module path when PathMatchingResourcePatternResolver's getResources(String) method is invoked with a location pattern using the "classpath*:" resource prefix. Specifically, getResources(String) first searches all modules in the boot layer, excluding system modules. It then searches the classpath using the existing Classloader-based algorithm and returns the combined results. Closes spring-projectsgh-28506
|
This issue has been resolved for inclusion in 6.0 M5. In the interim, feel free to try out 6.0 snapshots for applications deployed with patched modules. I've created a new repository for demonstrating the use of the Spring Framework with the Java Module System: https://github.com/sbrannen/spring-module-system That repository currently contains a single |
sdeleuze
added a commit
to sdeleuze/spring-framework
that referenced
this issue
Sep 21, 2022
spring-projectsgh-28506 introduces a big footprint regression on native, so it should for now be skipped when compiling to native images. Such support could potentially be re-introduced via spring-projectsgh-29081. Closes spring-projectsgh-29183
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In light of the findings from investigating #21515, we should introduce implicit support for scanning the module path whenever the
classpath*:resource prefix is used.This should allow existing applications relying on
classpath*:semantics to work when migrating to the Java module system (for use cases not already supported byClassLoader-based class path scanning).For example,
@ComponentScanshould effectively work the same when an application is deployed on the class path or module path.The text was updated successfully, but these errors were encountered: