Enable users to determine 'winning' source for a value - where is it coming from?

[hutchig]

When working with the issue described in #310. Resolving the cause of the problem took longer as it was not initially obvious that a environment variable was being overridden by a system property of the same name.

Should a 'source' of a value be identified by something in the API or by implementation specific debug/trace? (Or the latter making use of the former.)

[Emily-Jiang]

It is useful to find out which source serves the config. I think it can be down but not tie with a dedicated method. config.wrap() as discussed #84 might be a good fit for this. Any other useful details can be logged there. We can provide a noop impl for this. The implementor can choose what do you want to provide in this method. One good suggestion is to provide the info noted in this issue.

[Emily-Jiang]

@gunnarmorling what do you think? Is this a good use case?

[jmesnil]

We had a similar discussion in the ConfigJSR eclipse/ConfigJSR#10.

I think that the mp-config implementation should have tools to help resolve/analyze the configuration that is provided to the application.
However such tools can be built on top of the current API by separate tool or by the application itself

[dmlloyd]

Note that the immutability discussion in #432 and the caching discussion in #370 are directly relevant here. If the configuration is immutable, then a method could be provided which returns the ConfigSource for a key independently of accessing its value, with the understanding that the ConfigSource would not change between querying the key and retrieving the value. If the configuration is mutable, then there would need to be a way to atomically get the value and the source - and furthermore, if a Converter is in play which does validation, the location would have to be made available separately, before the converter has a chance to throw an exception.

[Emily-Jiang]

#43 should be able to figure out which configsource a particular config is coming from. By the way, I don't think the immutability has something to do with this one as the config_ordinal is static and newly added configure source will not be discovered after app starts.

[dmlloyd]

#43 should be able to figure out which configsource a particular config is coming from. By the way, I don't think the immutability has something to do with this one as the config_ordinal is static and newly added configure source will not be discovered after app starts.

It does. What I said above applies to the implementation option of a method which provides the ConfigSource of a given configuration key independently of accessing its value. If a config source can change, then a configuration key can disappear in the time between when a value is read and when the originating configuration source of that value is queried, and this has nothing to do with config ordinals.

[radcortez]

This is now possible with #551.