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.

Comment From: mbhave

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

Comment From: encircled

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

Comment From: philwebb

I've asked the OP to provide a sample

Comment From: 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.

Comment From: ibiko

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

Comment From: ibiko

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

Comment From: 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?

Comment From: 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

Comment From: 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?

Comment From: ibiko

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

Comment From: 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:'

Comment From: 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 https://github.com/spring-projects/spring-boot/issues/24798

Comment From: 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 https://github.com/spring-projects/spring-boot/issues/22497 @philwebb I believe this should have been pointed out in the changelog

Comment From: 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.

Comment From: 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.

Comment From: 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?

Comment From: 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.

Comment From: 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.

Comment From: mbhave

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