Spring Cloud Config dual bootstrap files behavior

Question

I have a setup where I am using the following:

• Spring Boot 1.5.13 with Spring Cloud Version Edgware.S3
• I have Spring Cloud Config Server and my Spring Boot apps are its clients
• Each app carries a bootstrap.yml with the config server uri and some other properties.
• Running containers on a Docker Swarm

I am currently passing Swarm secrets to the clients via a custom script which reads the files put into /run/secrets/ and creating a /config/bootstrap.properties file. It ends up looking like this:

spring.cloud.config.username=user
spring.cloud.config.password=password

My Docker image's default command is then this:

java -Djava.security.egd=file:/dev/./urandom -jar /${appName}.jar --spring.cloud.bootstrap.location=file:/config/bootstrap.properties"

Great. This is working without a problem. The app, seemingly, reads:

• The external bootstrap.properties to read in the config server's credentials
• The classpath bootstrap.yml to read in the rest of the config client props
• Fetches and reads in the config server's application-appName.yml
• Then reads the bundled application.yml from the classpath

Now. I'm moving the apps to Spring Boot 2.0.3 with Finchley.RELEASE and well, this breaks.

What is happening now is:

• The external bootstrap.properties is read in to get the config server's credentials
• The classpath bootstrap.yml is SKIPPED entirely (UNEXPECTED!)
• Fetches and reads in the config server's application-appName.yml
• Then reads the bundled application.yml from the classpath

The problem is that the properties that were set in the internal bootstrap.yml are now missing for the app so it blows up on start. I've been able to reproduce it outside the container environment by doing the same thing; point the app to an external bootstrap.properties. If I copy over the bootstrap.yml properties into the bootstrap.properties, then it works just fine. Also, if I don't provide an external properties file, then the internal bootstrap.yml kicks in without a problem. So it's either one or the other!

I'v also tried modifying the bootstrap location to include the default locations but no luck:

-- spring.cloud.bootstrap.location=file:/config/bootstrap.properties,classpath:,classpath:/config,file:,file:config/

Any ideas where to look next? Maybe there is a new spring.cloud.config property I'm missing? Or can anyone confirm which behavior is the correct behavior? Assuming they fixed a potential loophole in Finchley then I can just put this to rest and look for another solution. If it's 'broken' in Finchley, I guess an issue report is in order?

Answer 1

Well, some more digging showed that it looks like this is the new behavior:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide

The behavior of the spring.config.location configuration has been fixed; it previously added a location to the list of default ones, now it replaces the default locations. If you were relying on the way it was handled previously, you should now use spring.config.additional-location instead.

It didn't look to be Spring Cloud specific but I had nothing to lose. Changing my java command to use this new property did the trick:

--spring.config.additional-location=file:/config/bootstrap.properties

Thanks.