It's documented that you shouldn't use second-class options, such as KC_SPI_VAULT__KEYSTORE__PASS and you should see a warning about using a "second-class" option, but if one it can appear unmasked in show-config.
There's two related cases:
-
Usage of even the proper second class key in the env, e.g. KC_SPI_FOO__BAR__KEY, is turned into kc.spi-foo--bar--key by the KcEnvConfigSource, but the EnvConfigSource assumes that it's kc.spi.foo."bar".key - which is then shown in show-config
-
The legacy key format kc.spi-foo-bar-key in any config source.
I don't think we looked at using the FallbackConfigSourceInterceptor for the second case - it's just being handled in the MicroProfileConfigProvider.
Originally posted by @shawkins in #51013 (comment)
It's documented that you shouldn't use second-class options, such as KC_SPI_VAULT__KEYSTORE__PASS and you should see a warning about using a "second-class" option, but if one it can appear unmasked in show-config.
There's two related cases:
Usage of even the proper second class key in the env, e.g. KC_SPI_FOO__BAR__KEY, is turned into
kc.spi-foo--bar--keyby the KcEnvConfigSource, but the EnvConfigSource assumes that it's kc.spi.foo."bar".key - which is then shown in show-configThe legacy key format kc.spi-foo-bar-key in any config source.
I don't think we looked at using the FallbackConfigSourceInterceptor for the second case - it's just being handled in the MicroProfileConfigProvider.
Originally posted by @shawkins in #51013 (comment)