PathMatchingResourcePatternResolver does not consider manifest based classpaths [SPR-13685]

[spring-projects-issues]

Phil Webb opened SPR-13685 and commented

The PathMatchingResourcePatternResolver has a addAllClassLoaderJarRoots method which is used to find jar files on the classpath. The current implementation uses URLClassLoader.getURLs() to find items.

Unfortunately, it appears that URLClassLoader.getURLs() doesn't include elements that were added to the classpath in META-INF/MANIFEST.MF but not passed to java -cp. As Maven uses this technique to launch tests, it's pretty easy to get into a situation where tests fail but production code works.

This bug was originally raised in spring-projects/spring-boot#4438 and a repro project is included https://github.com/MichaelF25/spring-boot-messagesource-bug

---

Affects: 4.2.2

Issue Links:

• PathMatchingResourcePatternResolver cannot search for "classpath*" patterns in a jar file roots [SPR-12095] #16711 PathMatchingResourcePatternResolver cannot search for "classpath*" patterns in a jar file roots
• Provide subclassing hooks in PathMatchingResourcePatternResolver [SPR-12231] #16846 Provide subclassing hooks in PathMatchingResourcePatternResolver
• PathMatchingResourcePatternResolver provides duplicate resources with relative URL [SPR-14934] #19501 PathMatchingResourcePatternResolver provides duplicate resources with relative URL
• PathMatchingResourcePatternResolver provides duplicate resources when using classpath*: prefix combined with ant-style [SPR-15989] #20539 PathMatchingResourcePatternResolver provides duplicate resources when using classpath* prefix combined with ant-style
• PathMatchingResourcePatternResolver returns duplicate resources when using classpath*: prefix [SPR-16117] #20665 PathMatchingResourcePatternResolver returns duplicate resources when using classpath* prefix
• PathMatchingResourcePatternResolver should enforce consistent alphabetical sorting of directory content [SPR-14085] #18657 PathMatchingResourcePatternResolver should enforce consistent alphabetical sorting of directory content
• PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached [SPR-6295] #10961 PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached

Referenced from: commits 08748ec

0 votes, 6 watchers

[spring-projects-issues]

Phil Webb commented

One option that appears to work is to consider System.getProperty("java.class.path") when dealing with the system classloader.

PR #920

[spring-projects-issues]

Kazuki Shimizu commented

Running on Spring Boot 1.4, same resource is resolved form an executable jar file. I think it is related with this changes.
What do you think ? Is this bug ?

e.g )

demo.jar!
    - BOOT-INF
            - classes
                   + a.xml
                   + b.xml
                   + application.properties

Java code is :

package com.example;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.core.io.Resource;
import org.springframework.stereotype.Component;

import java.io.IOException;
import java.util.stream.Stream;

@SpringBootApplication
public class DemoApplication {

	public static void main(String[] args) {
		SpringApplication.run(DemoApplication.class, args);
	}

	@Autowired
	public void configureTestProperties(TestProperties properties) {
		Stream.of(properties.getResources()).forEach(resource -> {
			try {
				System.out.println(resource.getURL());
			} catch (IOException e) {
				e.printStackTrace();
			}
		});
	}

	@Component
	@ConfigurationProperties(prefix = "my.app.test")
	public static class TestProperties {
	
		private Resource[] resources;
	
		public Resource[] getResources() {
			return resources;
		}
	
		public void setResources(Resource[] resources) {
			this.resources = resources;
		}
	}
}

my.app.test.resources=classpath*:/**/*.xml

Run as :

java -jar demo.jar

Result is :

jar:file:/Users/xxx/demo.jar!/BOOT-INF/classes/a.xml
jar:file:/Users/xxx/demo.jar!/BOOT-INF/classes/b.xml
jar:file:demo.jar!/BOOT-INF/classes/a.xml
jar:file:demo.jar!/BOOT-INF/classes/b.xml
...

Expect is (Spring Boot 1.3.8.RELEASE) :

jar:file:/Users/xxx/demo.jar!/a.xml
jar:file:/Users/xxx/demo.jar!/b.xml
...

[spring-projects-issues]

Juergen Hoeller commented

@snicoll Could you please double-check this? Seems like a mix of absolute and relative paths...

[spring-projects-issues]

Kazuki Shimizu commented

Hi Juergen Hoeller and Stéphane Nicoll, Should I make a new Issue ?

[spring-projects-issues]

Stéphane Nicoll commented

Nope, sorry the issue isn't assigned to me and I missed that notification from my todo list.

[spring-projects-issues]

Andy Wilkinson commented

The fix for spring-projects/spring-boot#7003 may well be relevant here. It would be interesting to know if the behaviour differs between Spring Boot 1.4.1 and 1.4.2.

[spring-projects-issues]

Kazuki Shimizu commented

I've added repro project on my GitHub account. Please see https://github.com/kazuki43zoo/repro-PathMatchingResourcePatternResolver.

[spring-projects-issues]

Stéphane Nicoll commented

Andy Wilkinson there is a difference. 1.4.2 brings xml files located in nested JARs while 1.4.1 doesn't. But both versions exhibit the duplication. However something I didn't noticed initially is that the file is duplicated three times:

jar:file:/Users/snicoll/Downloads/test-SPR-13685/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/a.xml
jar:file:/Users/snicoll/Downloads/test-SPR-13685/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes/a.xml
jar:file:demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes/a.xml

Notice in the second line there is ! missing on classes!.

[spring-projects-issues]

Stéphane Nicoll commented

Thanks Kazuki Shimizu, I've just created #19501

[spring-projects-issues]

Kazuki Shimizu commented

Hi Stéphane Nicoll, Thanks for your work!! I'll watch the #19501.