Add ability to decorate ConfigSources

[dmlloyd]

It would be nice if there were some way to install global Converter decorators/interceptors (e.g. UnaryOperator<Converter>) which can enhance the conversion process.

This would enable an easy way to plug in various variable expansion capabilities.

I'll work up a possible implementation.

[dmlloyd]

This is actually quite difficult to do in the higher level APIs, because in the end, it's possible to query the ConfigSource for all of its properties and values which would bypass any converters. So, it might be better to implement this by wrapping the ConfigSource implementations themselves.

[dmlloyd]

Here are some example use cases:

• Value property expansion
• Key filtering and transposition
• Caching or copying for slow config sources
• Snapshot/point-in-time configuration views

[jmesnil]

@dmlloyd I'm not sure how much you're following microprofile-config development but we are working on the next release to address some of these issues:

• value property expansion
• snapshot
• caching

they are tracked by eclipse/microprofile-config#392

We do not have use case for Key filtering and transposition, could you provide some?

[dmlloyd]

Sure. Imagine you have a platform where you might want to have one configuration file with multiple "profiles". I might have most of my keys be the same, but a small number might have some variations, for example:

app.db.url=pgsql:...some production DB...
%dev.app.db.url=h2:...something trivial...

Then I start up my app in a mode where all ConfigSource instances are wrapped such that the %dev key is consulted first if I start with a certain flag.

[dmlloyd]

As for the other use cases, this might be a handy way to implement them. I've already got property expansion working locally (I wasn't going to bother upstreaming it because it definitely violates the current spec, but this can be revisited). Snapshot/caching aren't something I need right now but they seem like fairly obvious applications of the mechanism; good to hear these behaviors are going upstream.

[jmesnil]

Does the % in %dev has a special meaning or is it a convention to identify "special" prefix?

there is a proposed mechanism similar to your profile: https://github.com/eclipse/microprofile-config/pull/392/files#diff-f61262f6aeaf46e63969779a53065af8R111

It's using suffixes instead of prefixes but the idea is the same and allows to specify configuration per project stages (or envs):

app.db.url=pgsql:...some production DB...
app.db.url.dev=h2:...something trivial...

The code would have to specified these:

URL dbURL = config.access("app.db.url", URL.class)
          .addLookupSuffix(config.access("config.projectStage", String.class).build())
          .build()
          .getValue();

if config.stage prop has the dev value, the config would look at app.db.url.dev before looking at app.db.url

[dmlloyd]

I've just copied the convention used by Play. Plain suffixes are not a good idea though because there is a grammatical ambiguity.

[dmlloyd]

I'll comment such on the proposal.

[dmlloyd]

Solved by #68.