You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Following the discussion for #4869 it appears that when accessing the Config object from ConfigProvider.getConfig(), profiles is not taken into account.
Reading the spec, this is the prefered way to access the configuration programmaticaly
The current configuration of an application can be accessed via ConfigProvider#getConfig().
Expected behavior ConfigProvider.getConfig() take profiles into account.
Additional context
It has been suggested to use a ConfigResolver, but this is less obvious for a user and some internal Quarkus code already use ConfigProvider.getConfig() so it is a bug already present in Quarkus.
The text was updated successfully, but these errors were encountered:
The bug is that ConfigProvider.getConfig() and ConfigProviderResolver.instance().getConfig() are unfortunately returning different instances. This is codified in the existing bug report #4653#4512 (sorry, had written the wrong issue number).
@dmlloyd this is not #4653 as it's about GraalVM updates.
I was a mis-understanding relationship to profiles, but anyway, the important thing is to fix it to be able to offers an undertandable (and standard) way to access the config programmatically.
gsmet
changed the title
ConfigProvider.getConfig() should takes profile into account
ConfigProvider.getConfig() should take profile into account
Nov 15, 2019
Describe the bug
Following the discussion for #4869 it appears that when accessing the Config object from
ConfigProvider.getConfig()
, profiles is not taken into account.Reading the spec, this is the prefered way to access the configuration programmaticaly
https://github.com/eclipse/microprofile-config#design
Expected behavior
ConfigProvider.getConfig()
take profiles into account.Additional context
It has been suggested to use a ConfigResolver, but this is less obvious for a user and some internal Quarkus code already use
ConfigProvider.getConfig()
so it is a bug already present in Quarkus.The text was updated successfully, but these errors were encountered: