Consider moving "troubleshooting" methods to another interface about config HOT 2 OPEN

There are a lot of 'power user' use cases which I came across. in the last 12 years using that system.

Ops Analysis

1st for analysis purpose. Consider you have an app or jar which you did program, but it's not deployed under your control but at a customer. Now you get some bug report that something is not behaving like expected. The first thing you want to know is if app is setup correctly. I've written quite some different ways to do this. A simple JSP, a JSF form, etc. In DeltaSpike we even expose this info via a standard JMX bean. What does it contain?

• Infos about the ConfigSources itself. Their ordinal, the exact order in which they got picked up, their location (from which jar did properties get picked up?) etc.
• Infos about each configured value. For each key we want to know:
  • what is the effective value?
  • from which ConfigSource did it get picked up?
  • what is the native value? This is important if variable replacement is in place!
  • etc

In DeltaSpike one can even provide a ConfigFilter which has a separate filterValueForLogging https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/config/ConfigFilter.java#L48 which can be used to replace secret information with *********** and other useful features.

Power Use Cases

I've seen rather enhanced features built on top of the Apache DeltaSpike Config mechanism. People did implement their own multi-tenant logic by accessing the values in the different ConfigSources themselves. I've also seen additional format information by doing the handling themselves.
Of course that is not an everyday use case but it is certainly useful - and it is fully portable as the behaviour of ConfigSources is very well defined. Same applies ofc to mp-config.

from config.

The "power user" cases you mentioned all feel like implementation specific features.

Not something that exists at the Spec / API level here.

Lets take an example ...

Infos about the ConfigSources itself. Their ordinal, the exact order in which they got picked up, their location (from which jar did properties get picked up?) etc.

For Eclipse Jetty, there is no ordinal, I cannot emphasis this enough.
The whole ordinal concept in this Spec / API is meaningless, that is 100% an implementation specific concept and feature.
The ConfigSources in Eclipse Jetty come from a Topological Sort of the dependencies between technologies, their categories, and scopes.
Some come from the distribution (jetty-home), some come from the instance (jetty-base), some come from the technology, some come from discovery (eg: deployment), some come from the environment (eg: cloud), some come from the
Scope of a particular webapp, etc.
We have many paths of discovery of what the configuration looks like at the different viewpoints, command line, jmx view, logging, listeners, etc.
We consider all of this to be implementation specific.

from config.