Consider spring.profiles.default when processing configuration files

[janotav]

I believe that spring.profiles.default property does not work as documented.

Let's consider following two application property files:

application.properties:
spring.profiles.default=profile1

application-profile1.properties:
server.servlet.context-path=/foo

And corresponding application that simply prints server.servlet.context-path and profile values:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        ApplicationContext ctx = SpringApplication.run(Application.class, args);
        System.out.println("Context-path: " + ctx.getEnvironment().getProperty("server.servlet.context-path"));
        System.out.println("active profiles: " + Arrays.asList(ctx.getEnvironment().getActiveProfiles()));
        System.out.println("default profiles: " + Arrays.asList(ctx.getEnvironment().getDefaultProfiles()));
    }
}

When run without parameters, I get:

Context-path: null
active profiles: []
default profiles: [profile1]

When run with explicitly selecting profile1 on command line with --spring.profiles.active=profile1, I get:

Context-path: /foo
active profiles: [profile1]
default profiles: [profile1]

My expectation is that in the first (parameter-less) execution, context-path would be /foo because profile1 properties are loaded as default.

[wilkinsona]

You can't set spring.profiles.default in a configuration file (YAML or properties) and have it affect the loading of other configuration files. This is discussed in the comments in #1219. As described in the documentation spring.profiles.active can be used in a configuration file for your purposes instead.

[janotav]

If that default profile cannot be set from a configuration file at all, the value obtained through ctx.getEnvironment().getDefaultProfiles() should not reflect such value either. Yet, it returns profile1 value (see output above). This doesn't seem to be exactly consistent.

On the other hand, if the default profile can be set from a configuration, but loading of additional configuration files is then handled differently, this should be documented.

[wilkinsona]

If that default profile cannot be set from a configuration file at all

I didn't say that it could not be set, but that it cannot be set and have its value affect the loading of other configuration files.

the value obtained through ctx.getEnvironment().getDefaultProfiles() should not reflect such value either.

This is out of Boot's control as it's done in Spring Framework after config file processing has completed. The first time AbstractEnvironment.getDefaultProfiles() is called, a search is made in the environment's property sources for the spring.profiles.default property. If it's found, its value is used to set the environment's default profiles.

On the other hand, if the default profile can be set from a configuration, but loading of additional configuration files is then handled differently, this should be documented.

We already document the use of spring.profiles.active and spring.profiles.include for this purpose. No mention is made of spring.profiles.default in Spring Boot's documentation so I'm curious where the expectation that it would affect loading of profile-specific configuration files came from. If you have a suggestion for how Boot's current documentation could be improved, I would be more than happy to review and merge a pull request.

[janotav]

Thanks for your patience and thorough explanation. It's really appreciated.

I have to admit that this half-way behaviour (profile being reported other than one used for property loading) still sounds like a bug to me, but not worth pursuing anymore.

In terms of what got me there: I think that at least in my case the original misleading information came most likely from here:

• https://www.baeldung.com/spring-profiles

which is non-official source, but happens to be very high on the list if you google "spring boot default profile". Considering that practically identical report existed before (I searched for duplicates in "Open" issue only, so I missed it), it's likely that I'm not the last person to hit this.

[wilkinsona]

Let's take another look at this alongside #16023 and #15445 in 2.2.x. I'm not sure there's anything we can do, but it won't hurt to have another look.