Add note about change in processing order of configuration files to release notes

[philwebb]

See https://spring.io/blog/2020/08/14/config-file-processing-in-spring-boot-2-4#comment-5188826974

project/application.yml:

some-field: value

project/src/test/resources/application-test.yml:

some-field: value2

@ActiveProfiles("test")
TestClass...

@Value("${some-field}")

String someField;

When the test is run with spring boot 2.4.1 the value from application.yml is injected.

When the test is run with spring boot 2.3.6 the value from application-test.yml is injected.

When the test is run with spring boot 2.4.1 and spring.config.use-legacy-processing: true the value from application-test.yml is injected.

[mbhave]

@philwebb How do our smoke tests pass in that case?

[encircled]

I can't reproduce the reported issue in 2.4.1, nor in current master branch

[philwebb]

I've asked the OP to provide a sample

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[ibiko]

I have packaged the maven project as a zip file.
boot-2.4.1-config-bug.zip

[ibiko]

The behavior is reproducible when the spring.config.use-legacy-processing is set to false.

[encircled]

Hi, thanks for providing the sample.

Still can't reproduce your issue thou, I'm getting value1: value1-test regardless of value in application.yml and spring.config.use-legacy-processing. What OS/JVM are you using?

[ibiko]

It happens on two Systems:
System1:
OS: Linux Mint 20 Cinnamon
JDK: openjdk 14 2020-03-17
System2:
OS: openSuse Tumbleweed
JDK: openjdk 11.0.9.1 2020-11-04

[ibiko]

Have you modified the property 'spring.config.use-legacy-processing' in /application.yml when testing or have you created a new property in /src/main/resources/application.yml?

[ibiko]

In my tests it is enough to just modify the existing property in /application.yml to get the two different behaviors.

[pearsonradu]

I created a project to demonstrate this bug https://github.com/pearsonradu/spring-boot-24497. This project showcases the context I was in when I discovered this issue.

Essentially there are two spring profiles, test and dev. The application will run successfully with the dev profile active and use spring.config.import to import an external property file. Running the application with the test profile fails, saying

***************************
APPLICATION FAILED TO START
***************************

Description:

Config data location 'file:./config/additional.yaml' does not exist

Action:

Check that the value 'file:./config/additional.yaml' at class path resource [application.yaml] - 14:13 is correct, or prefix it with 'optional:'


Process finished with exit code 1

Additional, I have a test case with @ActiveProfiles("test") that will fail to run with the following error:

***************************
APPLICATION FAILED TO START
***************************

Description:

Config data location 'file:./config/additional.yaml' does not exist

Action:

Check that the value 'file:./config/additional.yaml' at class path resource [application.yaml] - 14:13 is correct, or prefix it with 'optional:'

[encircled]

Hi,
@ibiko I see now, let me check it again

@pearsonradu this is a slightly different issue, I've raised a separate issue for that #24798

[encircled]

Such behavior is inline with the documentation https://docs.spring.io/spring-boot/docs/2.4.0/reference/htmlsingle/#boot-features-external-config

Config data files are considered in the following order:

1. Application properties packaged inside your jar (application.properties and YAML variants).

2. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants).

3. Application properties outside of your packaged jar (application.properties and YAML variants).

4. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants).

The change is effective from 2.4.0 as part of #22497
@philwebb I believe this should have been pointed out in the changelog

[mbhave]

Thanks for the sample @ibiko.

@encircled Thanks for the suggestion. We should add a note about the change in behavior to the release notes.

[ideazinfinite]

Such behavior is inline with the documentation https://docs.spring.io/spring-boot/docs/2.4.0/reference/htmlsingle/#boot-features-external-config

Config data files are considered in the following order:

1. Application properties packaged inside your jar (application.properties and YAML variants).

2. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants).

3. Application properties outside of your packaged jar (application.properties and YAML variants).

4. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants).

The change is effective from 2.4.0 as part of #22497
@philwebb I believe this should have been pointed out in the changelog

Could you please clarify on how OP's issue about using @ActiveProfiles("test") annotation being ignored is in line with the documentation? I too am running into a similar issue as OP where the profile value set in @ActiveProfile is ignored and I can confirm that this behavior has changed between spring boot versions 2.4.1 and 2.4.2.

[mbhave]

It's not that the @ActiveProfiles("test") is being ignored. It's the presence of an application.yml outside of the packaged jar that causes this behavior because of the change in processing order of configuration files.

If you're seeing that the @ActiveProfile is ignored, could you provide a sample application that we can run to reproduce the issue?

[ideazinfinite]

It's not that the @ActiveProfiles("test") is being ignored. It's the presence of an application.yml outside of the packaged jar that causes this behavior because of the change in processing order of configuration files.

If you're seeing that the @ActiveProfile is ignored, could you provide a sample application that we can run to reproduce the issue?

I think I get that part, up until 2.4.1 having @ActiveProfile inside of a class was able to override the active profile but since upgrading to 2.4.2, it is being ignored and the ordering described above seems to apply.

[mbhave]

@ideazinfinite That is not the behavior I'm seeing with the sample provided above. I see the same behavior with 2.4.1 and 2.4.2. If you think you have found a bug in 2.4.2, please raise another issue with a small sample that can be run to reproduce it.

[mbhave]

Closing this issue as this has already been documented in the migration guide.