spring.config.additional-location as environment variable does not work correctly

[Fantaztig]

We have a central yml file containing properties for our databases and would like to generically add those to our spring boot services.
We just upgraded to spring boot 2.1.6
What I attempted was to set SPRING_CONFIG_ADDITIONALLOCATION as system environment variable pointing to the location of the application.yml containing the db properties.
Unfortunately, it wouldn't recognize the file, setting it with SPRING_CONFIG_LOCATION works fine however.
As far as I understood the file in the additional location needs to be named application.yml as long as spring.config.name is not set otherwise. I even tried renaming and formatting it to application.properties.
Is this the way it's supposed to be or did I anything wrong?

[snicoll]

@Fantaztig I am not sure what you've done or where the confusion comes from. The behaviour is described in the documentation. If that doesn't help, please share a small sample (github or project zip) with instructions to let us reproduce that locally.

[Fantaztig]

Okay, to clarify my confusion I made a simple demo project
https://github.com/Fantaztig/spring-boot-demo
It takes the message from the property greeting and prints it to stdout.

My expectation would be that I can set a system environment variable via
export SPRING_CONFIG_ADDITIONALLOCATION=file:/var/xy/.
Then I place an application.properties file in that folder, which has greeting defined eg.
greeting=Hello World!.

Now, when I start the application it should print "Hello World!", instead I get
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'helloWorldService': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'greeting' in value "${greeting}"

Edit: FYI, we are running our applications on RHEL 6/7 with jdk 1.8

[mbhave]

Thanks for the sample @Fantaztig. This looks like a bug to me. Instead of using the relaxed rules that we use for property binding, we are relying on Spring Framework's rules for getting a property from the System environment.

While we fix this, you should be able to SPRING_CONFIG_ADDITIONAL_LOCATION.

[skloessel]

Hello,

Is there still a bug in Spring Boot 2.2.1.RELEASE with "spring.config.additional-location"?

Consider that we've application.properties in the classpath with defaults:
Having

--spring.profiles.active=P1,P2,P3 and 
--spring.config.additional-location=/path/to/ .... 

/path/to/application-P1.properties
/path/to/application-P2.properties
/path/to/application-P3.properties

the -profile configurations are not loaded as expected in the order P3,P2,P1 ... or the default values defined in the classpath are not overwritten correctly. (the classpath provides profile based properties files too)

The override seems to work just for profile P3 (... the last listed active profile).
Properties in P2 do not become effective - default values from the classpath are used.

Many thanks.

[wilkinsona]

@skloessel Your problem doesn't appear to be related to this issue as you're not using an environment variable. If you think you may have found a bug, please open a new issue attaching a small sample project that reproduces the behaviour you have described above.

[virtualdxs]

Is this valid? I was under the impression that environment variables were not allowed to contain hyphens.

[mbhave]

@virtualdxs This issue isn't about hyphens in environment variables. It was about the recommended format for environment variables (uppercase separate by _) not working for spring.config.additional-location.

If you were referring to my comment, that was just a workaround till the fix was available. In any case, I might have meant ADDITIONAL_LOCATION as the workaround and I've updated that comment.

If you have any more questions, please ask them on Gitter or StackOverflow.

[Fantaztig]

I think ADDITIONAL_LOCATION didn‘t work either, however I’m not 100% sure about that.
@virtualdxs hyphens in environment variables are not allowed in Unix Systems afaik. E.g. when you start a process from within another java application it is possible though.