In post-processing the given environment of ConfigDataEnvironmentPostProcessor, add SpringApplication's additional profiles that are set programmatically into the given environment when legacy processing is used.

This commit updates the following areas:

  • Add configureAdditionalProfiles method into ConfigDataEnvironmentPostProcessor, that add the additional profiles into the given environment.

  • When legacy processing is used, call configureAdditionalProfiles method to add the additional profiles into the given environment.

  • Remove unnecessary configureAdditionalProfiles method in SpringApplication.

  • Supplement unit test for SpringApplicationTests.

Fixes https://github.com/spring-projects/spring-boot/issues/25704 Fixes https://github.com/spring-projects/spring-boot/issues/26189

Comment From: wilkinsona

Thanks for the pull request, @nguyensach. Additional profiles configured via SpringApplication are activated by including them in the Environment's active profiles:

https://github.com/spring-projects/spring-boot/blob/d1aaee46bbe329429eeab55aac554797255ea79e/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L557-L565

IIRC, this means that they should be picked up by ConfigFileApplicationListener without any special treatment. I believe this was the case in Spring Boot 2.3 and, ideally, we'd make it the case in Spring Boot 2.4 as well. If you explored this approach and it didn't work out, can you please explain what stopped it from working?

Comment From: nguyensach

@wilkinsona

Thanks for your information!

If you explored this approach and it didn't work out, can you please explain what stopped it from working?

In Spring Boot 2.4, when legacy processing is used and additional profiles configured via SpringApplication, it is not worked as expected because of the method configureProfiles of SpringApplication.

https://github.com/spring-projects/spring-boot/blob/4ad87a861d34174e9ea7209304985eaba929d738/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L552-L562

In Spring Boot 2.3, the implementation of the method configureProfiles of SpringApplication is like below. https://github.com/spring-projects/spring-boot/blob/73cab9cb0e59cb4902fb18804364a86890ccc31b/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L513-L526

In Spring Boot 2.3, by the method configureEnvironment of SpringApplication that calls the method configureProfiles, additional profiles configured via SpringApplication are activated by including them in the Environment's active profiles. Then, that Environment is passed into ConfigFileApplicationListener at the below point on ApplicationEnvironmentPreparedEvent event. https://github.com/spring-projects/spring-boot/blob/73cab9cb0e59cb4902fb18804364a86890ccc31b/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L345

Then, in ConfigFileApplicationListener, the additional profiles are loaded into the Environment's propertySources, therefore, in Spring Boot 2.3, the properties of the additional profiles is got by the Environment's getProperty.

However, In Spring Boot 2.4, the method configureProfiles of SpringApplication is empty, therefore, the additional profiles configured via SpringApplication are not activated by including them in the Environment's active profiles before jumping into ConfigFileApplicationListener. So, the additional profiles are not loaded into the Environment's propertySources.

IIRC, this means that they should be picked up by ConfigFileApplicationListener without any special treatment.

In Spring Boot 2.4, when using legacy processing, the additional profiles are not picked up by ConfigFileApplicationListener without any special treatment.

After rethinking about order of the additional profiles, the included profiles, the other actived profiles in the ConfigFileApplicationListener's initializeProfiles method, I fixed this PR. Could you help me to review my PR?

By the way, in my PR, the CI is fail at the gradle's spring-boot-project:spring-boot:checkstyleMain task. I run format task in my local pc but it is not auto correct for me. Is there any way to auto fix the issues of the checkstyleMain.

Comment From: wilkinsona

@philwebb could you take a look at this one please?

Comment From: wilkinsona

By the way, in my PR, the CI is fail at the gradle's spring-boot-project:spring-boot:checkstyleMain task. I run format task in my local pc but it is not auto correct for me. Is there any way to auto fix the issues of the checkstyleMain.

There's no auto-fix for Checkstyle problems, unfortunately. Looking at the diff, I suspect the problem is due to the changes to the imports. They need to be kept in their current ordering and not use wildcards.

Comment From: nguyensach

By the way, in my PR, the CI is fail at the gradle's spring-boot-project:spring-boot:checkstyleMain task. I run format task in my local pc but it is not auto correct for me. Is there any way to auto fix the issues of the checkstyleMain.

There's no auto-fix for Checkstyle problems, unfortunately. Looking at the diff, I suspect the problem is due to the changes to the imports. They need to be kept in their current ordering and not use wildcards.

@wilkinsona Thanks for your response! I will fix it manually.

Comment From: mbhave

@nguyensach This change makes sense to me. I have left some comments. Can you please take a look?

Comment From: nguyensach

This change makes sense to me. I have left some comments.

@mbhave I'm sorry! I don't see any of your comments. Can you please check it?

Comment From: mbhave

@nguyensach Sorry about that! I forgot to click on submit 🤦🏽‍♀️ Hopefully you can see them now.

Comment From: nguyensach

@mbhave Thanks for your review! I replied to all your comments.

Comment From: mbhave

Thanks for the PR @nguyensach. This has now been merged into main along with this polish commit.