Many MicroProfile specifications make use of the MicroProfile Configuration specification
for configuration. For simple usage patterns, different specifications tend to have a similar
approach. For more complex configuration patterns - the problems that we are trying to solve tend to come from a common palette but the particular solution arrived at can be different in each
specification group.

As well as looking odd, having different ways to solve configuration problems in different specifications means that MicroProfile as a whole has more 'surface area' for users to learn.
It also makes it easier to make mistakes in configuration which can be hard to resolve.

Here are some places that need ironed out:

Property Prefix - "mp.<spec-name>" ?

Some specs prefix all properties with "mp.<spec-name>" some do not.
Should each MicroProfile property name be prefixed with a "mp.<spec-name>" prefix?

Package qualifying class names in properties

There are places where an annotation classname appears or a specification sourced classname (e.g. Concurrency) appears in config property names, these classnames are not package qualified. E.g. Retry/maxRetries=30.
This is probably the right choice from a usability point of view.
This is particularly not a problem where the scope of the configuration property identifies a particular Java file.
It could become more of a problem for service wide defaults if more than one service
has a class with the same name.
The result is that we should have exclusive classnames in MicroProfile for classes that might need config override in the process environment.
The 'first' specification that owns a classname should own that name exclusively.

Where user classnames appear, these are expected to be package qualified.

Accounting for method signatures

There are places where is used. Currently there is no accounting for methods with the same name but different signatures.

Overriding for a particular scope.

Various specs consider overriding, either at particular annotation location, a particular class or
service wide (treated as global).
Overrriding at different scopes should be discussed generally.

The set of possible scopes is:

• class - <dotted-fully-package-qualified-classname>/<annotation-classname>/<parameter>
• package-prefix - '.(complicated as` is not a valid ENV variable char)
• package - <dotted-fully-qualified-package>/<annotation-classname>/<parameter>
• archive - ?
• service - <annotation-classname>/<parameter>
• globally - same as service
• named - ? Where an annotation has a named site
• non-structured - <classname>/methodname=single-paramer-value (e.g. ManagedExecutor/cleared=Transaction)

Precedence of config overlap - different scopes

Configuration which is more specific overrides configuration where the scope is more general.

For example, when multiple config properties are present, the property <classname>/<methodname>/<annotation>/<parameter> takes precedence over <classname>/<annotation>/<parameter>, which is followed by <annotation>/<parameter>.

Indexing Annotation Occurrences (from Concurrency)

The "1" in the Property name below refers to the occurrence of the 'methodmean in
org.eclipse.microprofile.example.ExampleBean/setCompletableFuture/1/ManagedExecutorCon fig/maxAsync=5

Precedence of config overlap - code versus process environment

Configuration from the environment overrides configuration in the code for all configuration
of equal of less specific scope in the code. This is a common approach across the specifications.
However, should code sited config that is more specific than process environment config take precedence? Or should environment config overrule coded config for all scopes it applies to?

When multiple config properties are present, the property <classname>/<methodname>/<annotation>/<parameter> takes precedence over <classname>/<annotation>/<parameter>, which is followed by <annotation>/<parameter>.

Overrides Ignored if No Annotation Present

Overrides just change the value of the corresponding annotation parameter specified in the microservice and nothing more. If no annotation matches the specified parameter, the property will be ignored.

Empty

In order to guarantee that empty string config values are interpreted properly, the MicroProfile Context Propagation implementation must interpret both of the following as indicating empty:

• empty array
• array containing the empty String as its singular element