CDI @ConfigProperty default value consistency should be enforced

If the same configuration property is given more than once via the @ConfigProperty annotation, they should be enforced to have the same default value string, or else an error should result.

This is a necessary prerequisite to #405; if multiple default values are allowed for a given property, then it becomes impossible to define which value would be returned for an expression string which references that property.

The specification text for @ConfigProperty should be updated to this effect.

[radcortez]

Additionally, we can consider to add an API to provide the default values and deprecate @ConfigProperty#defaultValue. But that can be done in a separate issue / PR in 2.1 or forward.

[jbee]

After discussing this in yesterdays weekly meeting I first grasped the entirety of this proposal. I try to summarised it again in my own words so that it might help others in getting an understanding.

The issue: The same property can be injected multiple times using @ConfigProperty where each occurrence could state a different defaultValue. Looking at each injection point alone this is fine. When looking at it in context of other features (caching, var expansion, …) the ambiguity causes issues.

The proposal is this: On deployment CDI

1. verifies that all defaultValue for any configuration property use the same default value or otherwise throws an exception
2. makes the defaultValue from annotations generally available by virtually putting them in a map and wrapping that map in a new ConfigSource with lowest priority so that these defaults become effective even for lookups where the default isn’t directly supplied.

The goal is to make defaults apply consistently independent of where and how the lookup was made.