0

My problem is similar to one described here (I don't override classpath explicitly): Spring application.yml not detected when running with -classpath

I have a SpringBoot application producing executable app.jar built with repackage goal. I have application.yml in root context of backend.jar which is a dependency of app.jar. I can run the app successfully from IDEA via MainClass:

SpringApplication.run(MyApp.class, args);

I can run the app successfully from terminal:

java -jar app.jar

However, the application fails to configure from application.yml when I run it locally as CloudFoundry does:

unzip app.jar
java org.springframework.boot.loader.JarLauncher

Spring will boot up and provide static content but fail at first attempt to access anything that requires data from configuration.

I've read through documentation and I can't figure out what is wrong with the classpath. From MANIFEST.INF I assume java -jar app.jar executes the same class as I do in the third example above.

Thanks for ideas.

zeratul021
  • 2,644
  • 3
  • 32
  • 45

1 Answers1

0

This turned out to be a classpath problem (duh!).

We had an 'forgotten' empty application.yml in dependency Y and an actual valid application.yml in our dependency X. Similar to the classes, only first occurrence of the resource on classpath is loaded by the classloader.

After enabling spring debug logging and examining ClasspathLoggingApplicationListener output one can see that the classpath order of dependencies within fatjar is different for the use cases described in question.

For java -jar nested JAR order seems to be hashed. For JarLauncher it is alphabetical.

Existing request to make this consistent: https://github.com/spring-projects/spring-boot/issues/9128

zeratul021
  • 2,644
  • 3
  • 32
  • 45
  • How did you solve the issue? I have the similar usecase where I need to lauch job using CommandLineJobRunner. I am using gradle bootRun task to lauch the mainClass CommandLineJobRunner with param. I am stuck with error : where datasource bean can't get initialized because application.yml is not picked. – JainAnk Apr 30 '18 at 17:19