Replies: 2 comments 1 reply
-
|
@shawkins +1 I don't object. At least, the Keycloak community has a backdoor when issues arise. As you said, quarkus.properties config source is not supported, so I think we can allow to be able to override Quarkus settings via this on our own risk. It also helps to improve scenarios for adding custom Quarkus/Quarkiverse extensions for this project https://github.com/mabartos/keycloak-quarkus-extensions, as there might be some potential overlap of properties inside the default Keycloak. |
Beta Was this translation helpful? Give feedback.
-
|
Also we already have code that will emit a warning when when a second-class option is used - that was mostly for direct usage of spi properties that have keycloak options, but I believe it will cover this case as well. |
Beta Was this translation helpful? Give feedback.
-
|
IMHO it makes sense that the Quarkus options config source had higher priority than other Keycloak config sources. That said, this change might be perceived as a breaking change. Though it is unsupported, so probably fine. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Users occasionally must set quarkus values, even though they are unsupported, and we later add superceding keycloak options - for example #38699 and #19453
Currently we make the introduction of such keycloak options immediately breaking to anyone who had been using the quarkus options. If instead we changed the presedence of how we look for values to consider the quarkus properties ahead of any indirect setting, then the change would not be initially breaking from a user perspective.
Since the direct usage of quarkus properties is not supported in any case this would not affect any supported scenarios.
cc @keycloak/cloud-native
Beta Was this translation helpful? Give feedback.
All reactions