Allow to fetch multiple config parameters as a Map

[rmanibus]

Description

As a:

• Application user/user of the configuration itself
• API user (application developer)
• SPI user (container or runtime developer)
• Specification implementer

...I need to be able to:
fetch multiple configuration parameters with same type as a Map

@ConfigProperty("my.prefix")
Map<String, String> configs

or fetch multiple configuration parameters with different type as a scoped Config

@ConfigProperty("my.prefix")
Config configs

...which enables me to:

Avoid the more generic

@inject
Config config

config.getValue("my.prefix." + myDynamicKey, String.class)
``

[OndroMih]

What's your usecase, @rmanibus ? This looks like a useful feature for end users but you indicated that you're raising this as a SPI user and specification implementer. I don't think that implementers or SPI users really need this, do they? In which situations?

[rmanibus]

Sorry I missclicked this. Fixed

[Emily-Jiang]

I am not sure what you are trying to achieve by putting the config values with the same type in a map. What is your use case?

[rmanibus]

I have a config that look like:

my.prefix.outputdir.chain1
my.prefix.outputdir.chain2
my.prefix.outputdir.chain3
my.prefix.outputdir.chain4

I think it would be easier to use this config like:

@ConfigProperty("my.prefix.outputdir")
Map<String, String> outputDirs

outputDirs.get(message.getChain())

[Emily-Jiang]

Can you take a look at #240 ? I think what you suggested can be achieved by that and it is nicely structured. If you agree, please close this. I plan to start with #240 soon.

[rmanibus]

I think that with 240 we still miss the ability to fetch a config parameter with a key that depends on a runtime value.
in fact the solution I proposed is not good because we miss the validation on startup (if I can get any string in the map, then I don't know which keys should be present).

However regarding an enum:

enum Chain  {CHAIN1, CHAIN2, CHAIN3 }

We could use:

@ConfigProperty("my.prefix")
Map<Chain, String> chainConfig

When I need to fetch a configuration with a key that is not known in advance (but that must be contained in the enum), we could just fetch it with:

chainConfig.get(Chain.CHAIN1)

And we can ensure that a configuration value exist for every value in the enum.

[essobedo]

When we need a dynamic configuration, it can be very helpful to use a map. For example, let's say that I want to keep in my configuration the custom reason phrases to return to the enduser according to the http status code.

I would like to have:

The expected code

@ConfigProperty(name = "reasons")
Map<Integer, String> reasonPhrases; // or eventually Map<String, String>

The expected configuration

reasons.200=My custom reason phrase for OK
reasons.201=My custom reason phrase for Created
...

Do you believe that it is a feature that can be considered in the near future?

[radcortez]

In SR Config we support maps like this: https://smallrye.io/docs/smallrye-config/main/mapping/mapping.html#_collections_config_mapping.

At the spec level, maybe we could add the support for it as well.

[essobedo]

@radcortez Hi, yes I'm aware of it, I already tested it, it works well. However, I'm currently migrating several projects from Dropwizard to Quarkus, and using it, needs a lot of changes in the current code because the configuration classes are (unfortunately) field based so it is simpler to rely on the annotations ConfigProperty and ConfigProperties instead of using interface that are by nature method based. Moreover, AFAIK, it is not standard, I rather prefer to rely on standard features if possible.

[radcortez]

Well, maybe I can implement that in SR Config side. No new API requires (or changes), but of course it probably won't work in other implementations.

[Emily-Jiang]

I think in this scenario, basically add the support of Map<String, Object>.

[essobedo]

Well, maybe I can implement that in SR Config side. No new API requires (or changes), but of course it probably won't work in other implementations.

@radcortez Good news! thx for that. If you are open to contributions, I could try to propose a PR for that in SR/Quarkus if you want

I think in this scenario, basically add the support of Map<String, Object>.

@Emily-Jiang thx for your proposal, it could be great too, please let me know if I can help in any ways to move this topic forward

[Emily-Jiang]

I think we can work on this issue after jakarta namespace alignment was done, which could be done soon hopefully.

[radcortez]

@radcortez Good news! thx for that. If you are open to contributions, I could try to propose a PR for that in SR/Quarkus if you want

@essobedo sure. please go ahead. you can do it in SR Config.

[otaviojava]

Hey, is there any news on it?
It is useful in several cases, such as complex configuration on JPA connection, NoSQL, JMS, etc.

I requested something similar to Jakarta Config:
jakartaee/config#104

[radcortez]

It is unlikely that this will be added to MP Config, since most of the effort is in Jakarta Config (which will take a while). Anyway, if anyone in the community wants to work on it, I'm happy to review it.

[rmanibus]

@radcortez I would be happy to work on it.
I'm not sure about what need to be included in this PR: documentation, tck and that's it ?

[radcortez]

Yes, spec and TCK.

[Emily-Jiang]

@rmanibus can you please provide a PR to address this issue?