PropertiesLauncher and loader.path property issue

See original GitHub issue

When I created an app. with ZIP layout, I move the lib/ folder outside the jar file and try to run this way. There are some weird behaviors that I see

I’m setting the loader.path=lib/ in the _application.properties_ file inside the jar, and it’s working.
I’m moving the _application.properties_ file outside the jar, and it’s not working, raising

        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
        at java.lang.Class.getDeclaredMethod(Unknown Source)
        at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContext
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at org.springframework.boot.loader.LaunchedURLClassLoader.doLoadClass(LaunchedURLClassLoader.java:170)
        at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:136)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        ... 5 more

I’m trying to set the property like -Dloader.path=lib/ but again it’s not working, same error above.
I put the _application.properties_ inside the jar file, and created another one outside the jar, putting other properties in it, and it worked again, read the properties from application.properties file outside the jar file successfully…

Is this expected behavior ?

Issue Analytics

State:
Created 8 years ago
Comments:9 (4 by maintainers)

Top GitHub Comments

1reaction

wilkinsonacommented, Oct 10, 2016

I’m moving the application.properties file outside the jar, and it’s not working

If you move application.properties to a non-standard location, then you need to use loader.config.location to tell the launcher where to look. For example -Dloader.config.location=./application.properties to look in the current working directory.

I’m trying to set the property like -Dloader.path=lib/ but again it’s not working, same error above.

I would guess that your command line was malformed. java -jar foo.jar -Dloader.path=lib/ won’t work as anything after -jar foo.jar is ignored. For example, you should use java -Dloader.path=lib/ -jar foo.jar instead.

I put the application.properties inside the jar file, and created another one outside the jar, putting other properties in it, and it worked again, read the properties from application.properties file outside the jar file successfully…

This sound like standard behaviour for externalised configuration. For general properties (as opposed to those that are property launcher-specific), application.properties inside the jar and outside will be used, with the latter taking precedence. See the documentation on externalised configuration for further details.

0reactions

wilkinsonacommented, Oct 10, 2016

I do not know yet if it is related to ZIP64 vs ZIP32 or to those restrictions mentioned in spring boot docs E.5.1 Zip entry compression

When the latter is encountered, an exception is thrown and it makes it impossible to read any nested jars so I doubt it’s that. I suspect it’s the former; see https://github.com/spring-projects/spring-boot/issues/2895.

getClassPathArchives is just skipping wrong path that is being delegated to it from loader.path … IMO fast failing will be better approach, but I might be wrong as I might not see the whole picture.

I believe the current behaviour matches that of the JDK. It will ignore non-existent paths that are passed in via -classpath.

This class PropertiesLauncher is called first even before Logging is being initialised

That has to be the case. The launcher is responsible for creating the class loader that will load the logging system. For this reason, PropertiesLauncher writes logs to System.out when loader.debug is true.

‘Invalid’ jar files from LaunchedURLClassLoader perspective being added to the class path using loader.path should also trigger some exception failing fast the running of the app, IMO.

This matches the JDK’s behaviour. For example, if you point -classpath to a corrupted jar file it doesn’t fail. I can see why that behaviour isn’t ideal in this case, but I’m reluctant to diverge even assuming it’s possible to do so.

Top Results From Across the Web

SpringBoot loader.path Unable to load external Jar

My problem is I can't seem to load any JDBC drivers from any jars that I drop into this directory, what am I...

PropertiesLauncher (Spring Boot 2.4.13 API)

loader.path : a comma-separated list of directories (containing file resources and/or nested archives in *.jar or *.zip or archives) or archives to append ......

Spring Boot 2 and external libs with the PropertiesLauncher

Spring will use the org.springframework.boot.loader.WarLauncher internally to start the application. But what if you need external libs which ...

How to use an external JAR in a Spring Boot application

We can instruct the PropertiesLauncher to search for additional JAR files in ... More in detail, we can rely on the property loader.path...

Spring Boot: Configuring a Main Class - Baeldung

DemoApplication Main-Class: org.springframework.boot.loader. ... Let's see how we can control this property using Maven and Gradle.