Support combined config values from multiple sources

In looking at possible solutions for MP Rest Client issue 73 - propagating HTTP headers, one issue that arose is how to allow different technologies (JWT, Metrics, etc.) to specify which headers they need propagated. MP Config seems like the most natural fit, but we would need to ability to read the specified config from multiple sources.

For example, JWT might specify that they need headers “A”, “B” and “C” propagated, but Metrics might need “X”, “Y”, and “Z”. In order for this to work the MP Rest Client implementation will need the combined list of headers A,B,C,X,Y,Z.

Here are some ideas for how this could be accomplished:

• each config source could use the same config property name, and the config consumer would need to somehow specify that it wants a combined (not overwritten) value - maybe a new annotation or new API to indicate.
• each config source could use a slightly different config property name, but the config consumer could then specify wildcards (i.e. JWT could specify mp.rc.propagateHeaders.forJWT=A,B,C and Metrics could specify mp.rc.propagateHeaders.forMetrics=X,Y,Z - then MP Rest Client could inject mp.rc.propagateHeaders.*)

The latter approach is less preferred, as it could lead to config collision but it does entirely avoid the issue of overwriting vs combining.

[smillidge]

I would discourage the use of getPropertyNames() as depending on the ConfigSource this could be a very expensive operation. For example a ConfigSource backed by a distributed key value store where property names are the set of keys in the store.

Therefore I don’t think wildcarding or stemming of config names is going to work as not all ConfigSources will be able to look up arbitrary key values.

[andymc12]

@struberg - to your point about returning a Map as opposed to a String[], I think that makes sense. Either should work for our case, but I completely agree that returning a Map of properties is generally more usable.

Thanks again!