Is there a way to specify a schema for the properties?

[jmini]

I hope this is the right place to ask this...

Is MicroProfile-Config providing a way to specify the values that are expected for each configuration key?
I guess I am looking for a sort of schema defining for each config key:

• Type (integer, long, string, …)
• Allowed values (in case of enum for example)
• Description
• Default value
• ...

Having a way to group config properties or to add some additional keys for filtering (like if you are deploying your application with or without additional modules) would also be interesting.

In the spring world, my understanding is that the Configuration Metadata would do something like this.

Is there something similar in the MicroProfile world?

[struberg]

Hi Jeremie!
No there is no such feature yet. Partly because spring-config works different and is pojo centric.
What I usually did in production is to have all the default values listed in property files within my app.
And there I also add documentation for each configured section (or value) via #.
Is this sufficient for you? We could also think about e.g. enhancing our @ConfigProperty annotation to contain a description which would be of purely descriptive nature without having an impact on the actual code. wdyt?

[dmlloyd]

Since there is no restriction on who can access a property with a given name, nor what default value they request for that name, nor what type or constraints are imposed on that property, this would seem impossible just from a cardinality perspective: depending on what usages you examine, you can end up with a variety of different schemas.

In Quarkus, however, we actually do have something like this. The Quarkus-specific configuration properties are all guaranteed to be unique, singly typed, with unambiguous requirement/default behavior and constraints, thus allowing the possibility of documenting configuration as well as generating a kind of machine-readable schema (see also #419). This also lets us log when unknown property names are used.

To do this at a spec-wide level would require some pretty drastic changes and limitations though: most significantly, configuration domains would have to be defined with bounded sets of properties and/or namespaces; properties would have to have pre-established conversion rules and constraints, as well as default values; property definitions would have to be completely unique per domain and would have to be known at the time that the configuration is loaded.

[bannmann]

(Disclaimer: I don't know whether this fits here or deserves its own issue. Please advise.)

I came here looking for ways to restrict allowed values for config properties. My immediate guess was "put BeanValidation constraints on the respective field", like this:

@Inject
@NotEmpty
@ConfigProperty(name = "my.string")
private String myString;

@Inject
@Min(0)
@Max(100)
@ConfigProperty(name = "my.number")
private int myNumber;

The expectation would be that if a value is supplied by some config source, the value needs to comply with all bean validation constraints specified. Note the similarity with regular Bean Validation usage, where a null field would be considered valid.

If a constraint is violated, a DeploymentException is thrown, similar to the case of missing properties.

So, was this considered at some point? Am I missing something that makes this approach impractical?

[radcortez]

Yes, we discussed a few times integration with Bean Validation, but we never got to a point to actually add it. I think there were other priorities.

Anyway, if for any chance you use SR Config, you can use Bean Validation annotations with SR ConfigMappings. Here is an example: https://github.com/smallrye/smallrye-config/blob/main/validator/src/test/java/io/smallrye/config/validator/ValidateConfigTest.java#L126