SpringApplication.setAdditionalProfiles, application-XXX.yml and SpringBoot2.4

[blacelle]

I consider a SpringApplication computing profiles on the fly, to be activated through SpringApplication.setAdditionalProfiles

I used this up to SprintBoot 2.3 to activate configuration in application-XXX.yml files

With SpringBoot 2.4, this seems not functional anymore, even with

Here is a snippet of code demonstrating the issue:

application-reproduce.yml:

reproduce.key: anything

@SpringBootApplication(exclude = org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration.class, scanBasePackages = "none")
public class RunReproduceMissingApplicationYmlApplication {

	protected RunReproduceMissingApplicationYmlApplication() {
		// hidden
	}

	@Configuration
	public static class SomeConf {

		@Bean
		public Void someBean(Environment env) {
			System.out.println("BEWARE: " + env.getProperty("reproduce.key"));
			return null;
		}

	}

	public static void main(String[] args) {
		System.setProperty("spring.config.use-legacy-processing", "true");
		// Will sysout a null value in SprintBoot 2.4: the bug (while OK with SpringBoot 2.3)
		startApp(args);
		// Will sysout something interesting: expected behavior
		System.setProperty(AbstractEnvironment.ACTIVE_PROFILES_PROPERTY_NAME, "reproduce");
		startApp(args);
	}

	private static void startApp(String[] args) {
		SpringApplication springApp = new SpringApplication(RunReproduceMissingApplicationYmlApplication.class);
		springApp.setWebApplicationType(WebApplicationType.NONE);
		springApp.setAdditionalProfiles("reproduce");
		springApp.run(args);
	}
}

In SpringBoot 2.3, I see twice BEWARE: anything: OK

In SpringBoot 2.4, I see:

...
BEWARE: null
...
BEWARE: anything

which demonstrate explicit profiles definition is OK, but simply exposing them through .setAdditionalProfiles lead them not taken in account for application-XXX.yml property sources.

[blacelle]

Hello. The issue is still present in SpringBoot 2.4.5

As I see multiple referring commits, should we expect it fixed within coming release? Thanks

I see the PR is actively being worked on. Thanks

[mbhave]

Closing in favor of PR #25817.