Loader-Path in Manifest File has No Effect

[hackingpath]

The Problem

I have a JAR in a ./lib/ directory and I want to have all JARs in that directory on my classpath.

This is my generated manifest file:

Manifest-Version: 1.0
Start-Class: biz.test.spring.boot.Application
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Loader-Path: lib                 <=============== look here
Spring-Boot-Version: 1.4.1.RELEASE
Main-Class: org.springframework.boot.loader.PropertiesLauncher

Actually even w/o any setting this should work(see):

loader.path (if empty) defaults to lib (meaning a local directory or a nested one if running from an archive). Because of this PropertiesLauncher behaves the same as JarLauncher when no additional configuration is provided.

But it does not so I tried with the MANIFEST.MF. But it has no effect. I also tried absolute paths. This feature is mentioned here:

Manifest entry keys are formed by capitalizing initial letters of words and changing the separator to “-” from “.” (e.g. Loader-Path). The exception is loader.main which is looked up as Start-Class in the manifest for compatibility with JarLauncher).

I also tried with a setting in application.properties but there is no effect either.

SUMMARY

3 Problems:

• lib/ folder not on classpath by default
• Loader-Path in MANIFEST.MF has no effect
• loader.path in application.properties has no effect

Workaround

I can run the application like this:

java -Dloader.path=lib -jar application-1.0.0.jar

Because I run it as init.d service I have *.conf file that sets loader.path in the JAVA_OPTS property.

But this doubles the effort during releases because the name of the JAR file contains the version and I need to update the link to the JAR AND the name of the *.conf file everytime.

Demo Data

I have a very simple Spring-Boot application to try that out:
https://github.com/PatrickTheFirst/spring-boot-test

The lib folder with the JAR is also checked in. But you can build the JAR on your own with this project:
https://github.com/PatrickTheFirst/demo-rest

If it works you will see a new Rest Servlet V1 servlet and you can call GET localhost:8081/rest/test/get.

System

Linux Mint 17.3 64-bit
Kernel Linux 4.4.0-15-generic x86_64
MATE 1.12.0

Spring Boot 1.4.1.RELEASE
Gradle 2.12

[philwebb]

I did the following with the sample:

$ gradle build
$ cp build/libs/spring-boot-test-1.0-SNAPSHOT-exec.jar .
$ ./spring-boot-test-1.0-SNAPSHOT-exec.jar &
$ curl localhost:8081/rest/test/get
Test String%

What am I missing?

[hackingpath]

It works because there is the file spring-boot-test-1.0-SNAPSHOT-exec.conf in the root directory which defines JAVA_OPTS=-Dloader.path=lib.

So my workaround is also working for you and you confirmed that my JAR is doing its job. If you now rename that *.conf file you hopefully will see the problem.

[wilkinsona]

loader.path (if empty) defaults to lib (meaning a local directory or a nested one if running from an archive).

The default is actually BOOT-INF/lib. I missed updating this documentation when we made that change from lib to BOOT-INF/lib in 1.4. Sorry for the confusion. That said, renaming your external lib directory to BOOT-INF/lib won't help. More on that below.

Because of this PropertiesLauncher behaves the same as JarLauncher when no additional configuration is provided.

But it does not

It does behave the same as JarLauncher with no additional configuration. You are running from an archive so the default for the loader path is to look for a nested directory inside the archive, just as JarLauncher does. If you want to use an external directory, you either need to unpack the archive or you need to configure the loader path.

I tried with the MANIFEST.MF. But it has no effect

Despite what the documentation claims, the support for using a MANIFEST.MF for the loader path doesn't exist. Sorry. For some reason the launcher only looks at application.properties and System properties. It does look in the manifest for Loader-Args and Start-Class. Unless I've missed something none of the other documented properties are read from the manifest.

I also tried with a setting in application.properties but there is no effect either.

Confusingly, PropertiesLauncher only supports a subset of the locations for application.properties that can be used once an application has launched. That doesn't appear to be documented. Sorry once again.

By default it will only look in classpath:BOOT-INF/classes/application.properties. Assuming you're running an executable archive, that means that the application.properties file needs to be in the BOOT-INF/classes directory inside the jar. If I add src/main/resources/application.properties that configures loader.path to your sample and rebuild it, it works as you had intended.

To summarise:

lib/ folder not on classpath by default

This should be documented as BOOT-INF/lib but, other than that, works as described.

Loader-Path in MANIFEST.MF has no effect

This is broken. PropertiesLauncher doesn't look in MANIFEST.MF for Loader-Path. A number of other properties appear to be similarly broken.

loader.path in application.properties has no effect

PropertiesLauncher only looks at classpath:BOOT-INF/classes/application.properties. We should probably try and remove this limitation.

[hackingpath]

@wilkinsona:

You solved a big problem for me:

PropertiesLauncher only looks at classpath:BOOT-INF/classes/application.properties.

I put a application.properties in my resources/ folder and it works w/o *.conf file. Awesome.

Thank you.

[philwebb]

We'll fixup the the documentation and what we can in 1.4. In 1.5 we're probably going to change the properties filename to avoid confusion with the full application.properties support that we can't really duplicate in the launcher.