Support subsets from a Config

[gastaldi]

Because the Config interface has a nice way to convert values and handle optional values, it would be nice if the API allowed to extract a subset of a Config to pass it as a parameter to methods that don't care about the external structure:

Eg.

app.foo.username=guest
app.foo.password=guest

SmallRyeConfig config = ...
Config subset = config.subset("app.foo");
// Now I can call methods taking the config as a parameter that only cares about the leaf nodes:
configure(subset);

public void configure(Config subset) {
   String username = subset.getValue("username",String.class); // This would return "guest"
}

[dmlloyd]

I think this is a good feature. The current internal APIs are not very friendly to this kind of approach though. It might be worth shaking things up internally because the same restrictions that make this feature hard to implement also make the config mapper very complex to implement, so addressing this might pay off in multiple areas.

[radcortez]

Thanks for the work @gastaldi

This is a very valid feature, and we should have it. On the other hand, I think we lose a lot of its potential by returning a Config instead of SmallRyeConfig.

Yes, right now, we cannot do that, but I'm also thinking for a while that SmallRyeConfig should become an interface. The MP Config API will not get any new updates, and we have to rely on many useful APIs we added in SmallRyeConfig directly. Some other projects like reactive messaging already have to reimplement their ownConfig version to handle Kafka config system.

I know that these can happen separately, but how about if we do this work here too? Or, you don't think we need to separate the SmallRyeConfig API @dmlloyd ?

[gastaldi]

Having SmallRyeConfig as an interface makes more sense I think. And given we have SmallRyeBuilder as the factory for this object (and not being instantiated directly), it shouldn't (hopefully) break existing code.

We could return a SmallRyeConfig by introducing a subclass with a String prefix and prepending that to the getValue/getOptionalValue calls if not null, but separating into a different delegating implementation is cleaner, so +1 to make SmallRyeConfig an interface.

[radcortez]

Do you want to have fun with it? Or do you prefer to do it as a separate PR? :)

[gastaldi]

I'll add to my never-ending TODO list :) Better make it as a separate PR to make sure we don't break anything ;)

[dmlloyd]

If we're not immediately planning on breaking compatibility, I would recommend adding a new interface which is implemented by SmallRyeConfig (and which might or might not extend Config) rather than changing the class to an interface which will break all existing code.