Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wilkinsona opened this issue Jan 11, 2021 · 9 comments
Assignees
Milestone

Comments

@wilkinsona
Copy link
Member

@wilkinsona wilkinsona commented Jan 11, 2021

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
Copy link

@perilbrain perilbrain commented Jan 11, 2021

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 philwebb self-assigned this Jan 11, 2021
@philwebb philwebb removed this from the 2.4.x milestone Jan 11, 2021
philwebb added a commit that referenced this issue Jan 11, 2021
Add a test to ensure that `spring.profiles.include` is not silently
ignored when used in a profile-specific file.

See gh-24733
@philwebb
Copy link
Member

@philwebb philwebb commented Jan 11, 2021

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
Copy link

@perilbrain perilbrain commented Jan 11, 2021

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
Copy link
Member

@philwebb philwebb commented Jan 12, 2021

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

@konradczajka
Copy link

@konradczajka konradczajka commented Jan 18, 2021

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
Copy link
Member Author

@wilkinsona wilkinsona commented Jan 18, 2021

@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
Copy link

@konradczajka konradczajka commented Jan 18, 2021

@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
Copy link

@workmanw workmanw commented Mar 23, 2021

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
Copy link
Member

@philwebb philwebb commented Mar 23, 2021

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants