Spring 5.1.2 PathMatchingResourcePatternResolver 检测 jar 根目录下的文件
Spring 5.1.2 PathMatchingResourcePatternResolver detects files on root of jar
我正在阅读有关 classpath* 的 spring 文档,我发现:
Please note that classpath*: when combined with Ant-style patterns will only work reliably with at least one root directory before the pattern starts, unless the actual target files reside in the file system. This means that a pattern like classpath*:*.xml will not retrieve files from the root of jar files but rather only from the root of expanded directories. This originates from a limitation in the JDK’s ClassLoader.getResources() method which only returns file system locations for a passed-in empty string (indicating potential roots to search).
当我在本地尝试这个时,我很困惑它对 jars 的根有效,例如:
test.txt 资源存在于 test2 根目录中(这是 class 我 运行 来自的应用程序),并且在 test 上也有 test.txt 依赖于测试2
项目测试 2:
@RunWith(JUnit4.class)
public class TestDriver {
@Test
public void test() throws IOException {
PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver();
System.out.println(Arrays.toString(resolver.getResources("classpath*:*test.txt")));
Enumeration<URL> enumeration= this.getClass().getClassLoader().getResources("");
int count=0;
while(enumeration.hasMoreElements()){
URL url= enumeration.nextElement();
System.out.println(url.getFile());
count++;
}
System.out.println(count);
}
}
输出:
[URL [jar:file:/C:/.../.m2/repository/com/test/1.0-SNAPSHOT/test-1.0-SNAPSHOT.jar!/test.txt]] --- > 当这个文本文件位于 jar 的根目录时如何检测到这个问题,根据文档,它不应该被检测到
来自 "this.getClass().getClassLoader().getResources("")" 只有 2 个根(测试 jar 不是其中的一部分):
/..../test2/target/test-classes/
/..../test2/target/classes/
2
文档提到了在这种特定情况下资源查找的可靠性。
您还可以在 PathMatchingResourcePatternResolver
javadoc 的这个警告部分的末尾阅读(重点是我的):
WARNING: Note that "classpath*:" when combined with Ant-style patterns
will only work reliably with at least one root directory before the
pattern starts
...
This ResourcePatternResolver
implementation is trying to mitigate the
jar root lookup limitation through URLClassLoader introspection and
"java.class.path" manifest evaluation; however, without portability
guarantees.
看来它适合你的情况。
我正在阅读有关 classpath* 的 spring 文档,我发现:
Please note that classpath*: when combined with Ant-style patterns will only work reliably with at least one root directory before the pattern starts, unless the actual target files reside in the file system. This means that a pattern like classpath*:*.xml will not retrieve files from the root of jar files but rather only from the root of expanded directories. This originates from a limitation in the JDK’s ClassLoader.getResources() method which only returns file system locations for a passed-in empty string (indicating potential roots to search).
当我在本地尝试这个时,我很困惑它对 jars 的根有效,例如:
test.txt 资源存在于 test2 根目录中(这是 class 我 运行 来自的应用程序),并且在 test 上也有 test.txt 依赖于测试2
项目测试 2:
@RunWith(JUnit4.class)
public class TestDriver {
@Test
public void test() throws IOException {
PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver();
System.out.println(Arrays.toString(resolver.getResources("classpath*:*test.txt")));
Enumeration<URL> enumeration= this.getClass().getClassLoader().getResources("");
int count=0;
while(enumeration.hasMoreElements()){
URL url= enumeration.nextElement();
System.out.println(url.getFile());
count++;
}
System.out.println(count);
}
}
输出:
[URL [jar:file:/C:/.../.m2/repository/com/test/1.0-SNAPSHOT/test-1.0-SNAPSHOT.jar!/test.txt]] --- > 当这个文本文件位于 jar 的根目录时如何检测到这个问题,根据文档,它不应该被检测到
来自 "this.getClass().getClassLoader().getResources("")" 只有 2 个根(测试 jar 不是其中的一部分):
/..../test2/target/test-classes/
/..../test2/target/classes/
2
文档提到了在这种特定情况下资源查找的可靠性。
您还可以在 PathMatchingResourcePatternResolver
javadoc 的这个警告部分的末尾阅读(重点是我的):
WARNING: Note that "classpath*:" when combined with Ant-style patterns will only work reliably with at least one root directory before the pattern starts
...
This
ResourcePatternResolver
implementation is trying to mitigate the jar root lookup limitation through URLClassLoader introspection and "java.class.path" manifest evaluation; however, without portability guarantees.
看来它适合你的情况。