java.lang.IllegalArgumentException: name org.springframework.boot.loader.LaunchedURLClassLoader.findResource

[Roronoa-Zoro]

please see below exception:

2019-11-22 14:34:52.829 - - [ERROR] main XXXXXXFactory  failed to load properties file: classpath:config/app.properties
java.lang.IllegalArgumentException: name
        at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:658) ~[?:1.8.0_45]
        at sun.misc.URLClassPath.findResource(URLClassPath.java:188) ~[?:1.8.0_45]
        at java.net.URLClassLoader$2.run(URLClassLoader.java:569) ~[?:1.8.0_45]
        at java.net.URLClassLoader$2.run(URLClassLoader.java:567) ~[?:1.8.0_45]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_45]
        at java.net.URLClassLoader.findResource(URLClassLoader.java:566) ~[?:1.8.0_45]
        at org.springframework.boot.loader.LaunchedURLClassLoader.findResource(LaunchedURLClassLoader.java:58) ~[xxx-server-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]

When we run java -jar xxx-server-1.0.0-SNAPSHOT.jar in local macbook, it's ok,
we run it in our test env, we get those exception. (centos 6.8)

below code triggered above exception:

URL url = Thread.currentThread().getContextClassLoader().getResource(file);

file is String, and we try to use "classpath:config/app.properties", "classpath*:app.properties", "config/app.properties", we all get above exception.

jdk:1.8
springboot:2.2.1
spring: 5.2.1

Can you please figure it out? Thanks a lot.

[wilkinsona]

We can try to figure it out, but we'll need some more information to be able to do so. Can you please create a minimal sample that reproduces the problem and share it with us by zipping it up and attaching it to this issue?

Given that this works for you on macOS but fails on CentOS, there's a chance that the problem is operating system- or environment-specific so any information about your macOS environment and your CentOS environment and the differences between them would also be useful.

[Roronoa-Zoro]

We can try to figure it out, but we'll need some more information to be able to do so. Can you please create a minimal sample that reproduces the problem and share it with us by zipping it up and attaching it to this issue?

Given that this works for you on macOS but fails on CentOS, there's a chance that the problem is operating system- or environment-specific so any information about your macOS environment and your CentOS environment and the differences between them would also be useful.

Thanks a lot for your reply, there's another information, Thread.currentThread().getContextClassLoader() is Launcher$AppClassLoader when I run in IDEA, but LaunchedURLClassLoader in test environment(centOS).
I will create a sample later.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[woodforda]

Hi,
I'm actually having this issue as well. In my case it's to do with finding a resource (as stream) which looks something like this C:\Users\woodford/.keystore (this is coming out of Apache CXF org.apache.cxf.configuration.jsse.SSLUtils - calling soap service). Once the getResourceAsStream is called I receive the IllegalArgumentException.

I'm in a large application and am trying to isolate it in a repeatable test. Linux works fine... windows fails - only when using the fat jar. Boot 2.2.4. Java 1.8

cheers,
Andrew

[woodforda]

pretty easy to duplicate - https://github.com/woodforda/issue-classloader

See readme for details.

[wilkinsona]

Thanks for the reproducer, @woodforda. We'll take a look.

[woodforda]

I suspect this is not an issue. It's due to the MalformedURl (which is from rubbish CXF code).

If I force usage of the URLClassLoader it too has the same issue. It's just that it's not normally the class loader you get when running another way... (i.e. not fat jar).

I have to work around the CXF defaults - currently just setting javax.net.ssl.keyStore to something non existent and compliant works - though doesn't leave a pleasant taste.

[wilkinsona]

Thanks, @woodforda. The differences in behaviour between the system class loader and a URL class loader are unfortunate. In the past, we've considered trying to work around them but decided not to do so (see #1744 and #2057 for example). I still think that was the right decision so I'm going to close this one again. Thanks for sharing your findings. Hopefully they'll help others in the future.