Qualified configuration keys

[Arthur De Magalhaes]

Hey everyone,

Do we have examples in any of the MicroProfile specs that use an app-qualified key for MP Configuration?  

For example, let's say our spec defines the key "microprofile.openapi.servers" that we wish to apply to different apps.   If we put that inside the app's "META-INF/microprofile-config.properties" then we're ok.  But how about if we're using system env variables, or something framework-wide like kubernetes config maps, how do we make sure that this key is mapped only to a particular application?

One option is to use the context root in the key, but you could potentially also have colliding context roots in the same system (ie: multiple instances of the same app).

Any guidance from MP Config on this?

- Arthur

[Ondro Mihályi]

This isn't yet covered by the specifications. All the mandatory config sources are JVM specific except properties file, which is deployment specific.

Implementations may offer a way to isolate configuration for different deployments or a user has to provide a config source that does the translation e.g. with the context root prefix. For example, Payara implementation provides a built-in config source that maintains configuration for specific deployed apps. I think there are no plans to include this in the spec yet. You are free to raise an issue for MP config in the github repo if you have a usecase for it and want it standardized.

--Ondro

[Emily Jiang]

Ondro was right. All system properties or environment variables are applicable to all apps. For any app specific configuration, it is either specified inside the app or a custom config source. Actually, you can create a custom config source to parse the properties from environment variables.

e.g. app1.hostname=xxx
map to hostname=xxx in app1

create a config source in app1 and read the environment variables and remap the properties.

Feel free to raise an issue in mp config for further discussion.

Emily

[Mark Struberg]

+1 Note that this allows vendors to fulfil the wishes of their customers for certain situations. The SPI itself is certainly powerful enough to cover all those requirements. 

But note that such things may not be required in all cases and we don't want to put any burden on the server in cases where we don't need it.

All in all the beauty of the approach is the strict split of the user facing API which is totally decoupled from the integration SPI.

LieGrue,

strub