Skip to content

Provide a configuration validation mechanism #10030

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

Open
snicoll opened this issue Aug 17, 2017 · 6 comments
Open

Provide a configuration validation mechanism #10030

snicoll opened this issue Aug 17, 2017 · 6 comments
Labels
theme: config-data Issues related to the configuration theme type: enhancement A general enhancement
Milestone

Comments

@snicoll
Copy link
Member

snicoll commented Aug 17, 2017

It would be nice if Spring Boot had a specific flag that would turn on extensive configuration validation, something similar to what we have with --debug (--config-validation?).

Let's say the user made a typo in a property or edited a file used by the config server with no assistance. If you know what you are looking for and the application starts and you have the actuator you can hit /application/configprops to see if the property has been bound properly. This works but we could do better.

The binding has already an option to fail if we are not able to bind a particular property (see @ConfigurationProperties#ignoreInvalidFields). One idea would be to have a mode where:

  • This flag is turned on for everything
  • For every failed attempt at binding a property we would keep a reference to the failure (rather than throwing an exception as this flag currently does)
  • If there are some unbounded properties, throw an exception coupled with a FailureAnalyzer that provides a nice and readable report (We do have some concept of origin of the property in 2.0 so we should use that)

I am pretty convinced that turning on this mechanism on a perfectly valid application will generate false positive but we may find a way to mitigate that.

This issue related to #9936 and, IMO, should supersede it.

@snicoll snicoll added for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Aug 17, 2017
@philwebb philwebb added priority: low type: enhancement A general enhancement and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Sep 1, 2017
@snicoll snicoll added the theme: config-data Issues related to the configuration theme label Sep 1, 2017
@bclozel bclozel added this to the 2.x milestone Feb 8, 2019
@jkubrynski
Copy link
Contributor

Any progress with this issue? Being unable to easily debug such issues is really a pain in the neck

@copitz
Copy link

copitz commented Oct 25, 2019

As with #12601 ConfigurationProperties#ignoreInvalidFields will probably be deprecated, are there concrete plans to implement this?

@philwebb
Copy link
Member

We don't have any immediate plans to look at this one. We have quite a few other strategically important issues that we need to look at before this one.

@copitz
Copy link

copitz commented Oct 29, 2019

Ok, thank you

@Lacritz
Copy link

Lacritz commented Dec 5, 2019

Any strategies to bypass the issue currently?

Having quiet some issues with not validating configuration properties before reloading the application entirely
Is there anything we can contribute for this particular issue?

@Toerktumlare
Copy link

we are very interested in this feature, as we have configuration properties that are managed by non-developers that might use IDEs that dont display properly if configuration syntax is correct.

I was looking for an option to hard fail a service startup if there is an unknown property (all properties) and was suprised when i failed to find such feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
theme: config-data Issues related to the configuration theme type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

7 participants