Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support combined config values from multiple sources

See original GitHub issue

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.

Issue Analytics

  • State:open
  • Created 5 years ago
  • Comments:18 (14 by maintainers)

github_iconTop GitHub Comments

smillidgecommented, Sep 3, 2018

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.

andymc12commented, Sep 10, 2018

@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!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Combining Configuration Sources - Apache Commons
CombinedConfigurationBuilder now allows combining multiple configuration sources to a single CombinedConfiguration object. The sources to be ...
Read more >
A common way of managing configurations for multiple ...
This article intended to share ideas and solutions to address some challenges related to Configuration Management, especially in the cloud ...
Read more >
How to Configure Multiple Data Sources in a Spring Boot ...
Learn how to configure multiple datasources using Spring Boot and Hiberanate. In this example, you will see how to configure 3 different ......
Read more >
Spring Boot and multiple external configuration files
When resolving properties (i.e. @Value("${myprop}") resolving is done in the reverse order (so starting with 9). To add different files you can use...
Read more >
Config sources to support full remote config and individual ...
The config sources / value sources concepts enhance Collector configuration capabilities while keeping full backwards compatibility.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found