spring.profiles.include and spring.profiles are not used by the new config data code. However, they are still valid if legacy processing is switched on. We should consider if we want to deprecate them in the metadata.

We also need to update the documentation which mentions spring.profiles.include here.

Comment From: philwebb

We currently still support spring.profiles, but we should log a warning. I think we should update InvalidConfigDataPropertyException to throw an exception if spring.profiles.include is used.

Comment From: perilbrain

+1 to @mbhave Please do a hard fail if spring.profiles.include is used. I had a setup like

  • application.properties.example
  • application-security.properties.example
  • .gitignore
  • application-common_pg.properties
  • application-common.properties
  • application-local_minepg.properties
  • application-local_mine.properties
  • application-local.properties
  • application-prod.properties
  • application.properties
  • application-security.properties
  • application-stage.properties

Where .gitignore ignores has

application-security.properties
application.properties
application-local_*.properties

and every major profile such as prod, stage etc has at top

spring.profiles.include=common,common_pg,security
# ...

In a new project everything was working on local but suddenly blasted on staging. I was unable to figure out the problem until I started debugging the spring boot source code. There I found @Deprecated in spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/context/config/ConfigFileApplicationListener.java which led to a new discovery that spring.profiles.include is deprecated. Now after 5 days of headache I was able to figure this out which is not going to be easier for a new developer. Better do a hard fail if legacy flags are not available.

Comment From: wilkinsona

Thanks for sharing your experience, @perilbrain. We started failing hard in 2.4.0.M2 (this issue) but this was then relaxed in 2.4.0.M3 to allow spring.profiles.include to be used in non-profile-specific documents. I've opened https://github.com/spring-projects/spring-boot/issues/24733 so that we can improve the situation.

Comment From: AJMcDee

Hi there, I've just come across this exact issue as the other user (only seeing this when pushing to stage!) when updating from a much older version of Spring Boot.

Am I right in thinking that in 99% of cases, updating to spring.profiles.active is the right way to 'include' other properties?

I'm pretty new to Spring Boot configuration/updates so just want to check that I'm on the right track, and also leave a trail for any other noob devs who come across this thread.

Comment From: philwebb

@AJMcDee It's hard to offer specific advice without more details, but generally speaking the spring.config.import property is a better option if you want to include other property files. This was only introduced in Spring Boot 2.4, so there are still a lot of applications out there that use profiles in order to import additional files. There's some details about this in this blog post. There's also a what's new video that covers some of it.