spring.profiles.include is silently ignored when used in a profile-specific document

[wilkinsona]

See #22693 for the introduction of failing hard and #22944 which relaxed things a little to allow its use in non-profile-specific documents. As things stand, it would appear that spring.profiles.include is being silently ignored when used in a profile-specific document.

At the least, I think we should update the release notes on the wiki as there's no mention of spring.profiles.include at the moment. Ideally, I think we'd also fail hard when spring.profiles.include is used in a profile-specific document. Flagging for team attention to see what the rest of the team thinks.

[perilbrain]

But please allow use of legacy flags. I have reverted to old method as the new method is yet unable to address few problems( #24720 ) and will take some time to mature when new issues pop up.

[philwebb]

I've been unable to replicate this with the latest 2.4.x. @perilbrain Do you have a sample project that shows the silent failure?

[perilbrain]

I've been unable to replicate this with the latest 2.4.x. @perilbrain Do you have a sample project that shows the silent failure?

In #24720 I have attached a file. All you need is to remove spring.config.use-legacy-processing=true from application.properties after bootstrapping. Here is what you'll see

With application.properties like:

# ==========================
# Dont touch legacy support
# ==========================
spring.config.use-legacy-processing=true

spring.profiles.active=local

result will be

$> http :8080/who
Active Profile Details: envType=application-local.properties, password=prod, common='from_common_profile'

When legacy removed in application.properties

# ==========================
# Dont touch legacy support
# ==========================
# spring.config.use-legacy-processing=true

spring.profiles.active=local

result will be

$> http :8080/who
Active Profile Details: envType=application-local.properties, password=MissingPassword, common='MissingCommon'

And yes application keeps on running without any hard fail.

[philwebb]

Thanks @perilbrain, I made a simple typo which is why my test didn't fail 🤦

[konradczajka]

Hi,
I'm not sure whether I should create a separate issue for my problem so I'll describe my problem here and, if asked, write it down again.

I'm currently in a process of migrating our services configuration from the old solution to Spring Cloud. Yesterday I created a little application which would be used for demonstrating the solution to my colleagues. I used the newest version including the bugfix for this issue. My app crashed. Reverting the Spring Boot version to 2.4.1 fixed the problem.

Our configuration repository structure looks quite regular. An excerpt:

/cloud-config-demo/cloud-config-demo.yml
/application.yml
/application-rabbitmq.yml

I wanted to reduce each app's configuration that is provided at startup to the bare minimum (i.e. the config server uri only, all other stuff including active profiles declarations would be externalized) so I declared that my demo app uses rabbitmq properties by adding spring.profiles.include=rabbitmq to demo-app.yml. On 2.4.1 everything works fine:

• The app is started without any profile
• It makes a request to the config server using the default profile: <config-server-uri>/cloud-config-demo/default
• In response it receives both "default" and profiles-specific property sources (including application-rabbitmq.yml)
• The app notices and applies the additional profile defined in cloud-config-demo.yml and then applies profile-specific configuration (application-rabbitmq.yml)

After upgrading the Spring Boot to 2.4.2 the app crashes at the very start with exception:

21:23:42.241 [main] ERROR org.springframework.boot.SpringApplication - Application run failed
org.springframework.boot.context.config.InvalidConfigDataPropertyException: Property 'spring.profiles.include' imported from location '[ConfigServerConfigDataResource@a43ce46 uris = array<String>['http://config-server'], optional = false, profiles = list['default']]' is invalid in a profile specific resource [origin: Config Server ssh://config-repo/cloud-config-demo/cloud-config-demo.yml:8:14]

Initially I thought that maybe a dash in the app (and its config file) name is interpreted as a name/profile separator but when I moved spring.profiles.include property from cloud-config-demo.yml to application.yml I got the same error (but mentioning the application.yml).

This is a slightly trimmed response from the config server (<config-server-uri>/cloud-config-demo/default):

{
  "label": null,
  "name": "cloud-config-demo",
  "profiles": [
    "default"
  ],
  "propertySources": [
    {
      "name": "ssh://config-repo/cloud-config-demo/cloud-config-demo.yml",
      "source": {
        "spring.profiles.include": "rabbitmq"
      }
    },
    {
      "name": "ssh://config-repo/application-rabbitmq.yml",
      "source": {
        "spring.rabbitmq.addresses": "...",
        "spring.rabbitmq.password": "...",
        "spring.rabbitmq.username": "..."
      }
    },
    {
      "name": "ssh://config-repo/application.yml",
      "source": {
        ...
      }
    }
  ],
  "state": null,
  "version": "..."
}

InvalidConfigDataPropertyException throws an exception during processing of ConfigDataEnvironmentContributor with this configuration. The contributor is marked as profileSpecific and therefore it's forbidden for it to contain "profiles properties".

In my opinion it should be permitted to specify profiles in an external configuration as long as particular file is not profile-specific.

I hope what I described makes sense. I'd gladly prepare a demo that reproduces this behavior.
Maybe it's not the Spring Boot's but Spring Cloud's problem. Or maybe there's a reason I shouldn't specify profiles in my config repo. I'd be very grateful for any response.

[wilkinsona]

@konradczajka Thanks for letting us know. I'm not sure that I have followed the description of the problem. For example, it's not clear to me where demo-app.yml fits in. This issue's closed and changes for it were released in 2.4.2 so to allow us to continue to investigate, please open a new issue. If you do create one, please include a minimal sample that reproduces the problem either as a zip attached to the issue or as a link to a separate repository on GitHub. A sample will help to remove any confusion about how you have set things up and the role that each file is intended to have.

[konradczajka]

@wilkinsona Thank you for the reply. It was a mistake - it should be cloud-config-demo.yml instead of demo-app.yml. I'' create a separate issue regardless.

[workmanw]

We ran into this issue when upgrading to 2.4.2 from 2.3.x. We were using spring.profiles.include to bootstrap logging settings and it was not being silently ignored. It was actually working as expected for us. Perhaps it's due to how early in the life cycle Spring initializes logging. Regardless this is a breaking change for us and so far I have not been able to find a work around. Using spring.profiles.active does not work because logging configuration is already initialized when this value is resolved and thus it is too late.

[philwebb]

@workmanw It sounds like that might be a related but different issue. Can you open a new report and if possible provide a sample application that we can run?