We use the "multi properties files in one" feature of Spring Boot 2.4.

With the change from Spring Boot 2.4.1 to 2.4.2 the following does no longer work:

application-xxx.properties

yyy=1
#---  
spring.config.activate.on-profile=zzz
yyy=2

org.springframework.boot.context.config.InvalidConfigDataPropertyException: Property 'spring.config.activate.on-profile' imported from location 'class path resource [application-xxx.properties]' is invalid in a profile specific resource [origin: class path resource [application-xxx.properties] - 28:35]
    at org.springframework.boot.context.config.InvalidConfigDataPropertyException.lambda$throwOrWarn$1(InvalidConfigDataPropertyException.java:121) ~[spring-boot-2.4.2.jar:2.4.2]
    at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
    at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1087) ~[?:?]
    at org.springframework.boot.context.config.InvalidConfigDataPropertyException.throwOrWarn(InvalidConfigDataPropertyException.java:118) ~[spring-boot-2.4.2.jar:2.4.2]
    at org.springframework.boot.context.config.ConfigDataEnvironment.checkForInvalidProperties(ConfigDataEnvironment.java:349) ~[spring-boot-2.4.2.jar:2.4.2]

If I incorrectly used this feature I apologize upfront.

Comment From: wilkinsona

Thanks for the report. I was going to close this as a duplicate of #24941 but this case is a little different.

The change in behaviour is due to https://github.com/spring-projects/spring-boot/issues/24733. The intent of this issue was to start failing when a property is used that was previously being silently ignored. However, in this case the property wasn't being silently ignored. With the example above, when the xxx and zzz profiles are active, Spring Boot 2.4.1 sets the value of yyy to 2. In 2.4.2, the application fails to start.

We'll need to decide how we want to handle spring.config.activate.on-profile when used in a profile-specific file.

Comment From: markusheiden

It would be nice, if you consider the combination of profile specific files with on-profile as feature, because it allows for better structuring thus smaller properties files.

Comment From: wilkinsona

We're going to try to support spring.config.activate.on-profile in a profile-specific file.

Comment From: larsduelfer

If I get the intention right from @markusheiden it would indeed be benefitial to have multiple yaml files contains application properties and each files is sub-structured in sections having their own value for spring.config.activate.on-profile. This way, larger setups with lot's of properties would be very well supported.

Example:

application-logging.yaml

spring:
  config:
    activate:
      on-profile: production
logging:
  level:
    ...
---
spring:
  config:
    activate:
      on-profile: staging
logging:
  level:
    ...
---
spring:
  config:
    activate:
      on-profile: local
logging:
  level:
    ...

You can then organize all logging configuration properties in one property file and depending on the active profile, the part of the yaml file is used.

@wilkinsona: Is that what you have in mind by saying "We're going to try to support spring.config.activate.on-profile in a profile-specific file." in your comment above? Thanks in advance for a short answer on this.

If I understand correctly how it works in 2.4.1, you need to have any of the following profile combinations in your list of active profiles: "logging, production", "logging, staging" or "logging,local". Is this correct? I never tried this myself with 2.4.1 since we are currently upgrading directly to 2.4.2.

Another option would be, to ignore the suffix of the filename application-suffix.yaml and just interpret this file as another application.yaml. This way, the files won't get too long and the profile-specific config for logging is just activated by having any of the following profiles in the list of active profiles: "staging", "production" or "local".

Comment From: wilkinsona

@larsduelfer Short answer: yes.

Slightly longer answer: Yes, although you may want to use a spring.config.import to pull in a configuration file that encapsulates all your logging-related properties without having to activate the logging profile.