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
Every know and then I come accross the case of having an Optional configuration property that the user is expected to provide and a secondary boolean flag that pretty much tells Quarkus to try and infer the value of the Optional property.
/** * The gRPC port to use for the probe (the format is either port or port:service). */@ConfigItemOptional<String> grpcAction;
/** * If enabled and `grpc-action` is not provided, it will use the generated service name and the gRPC port. */@ConfigItem(defaultValue = "false")
booleangrpcActionEnabled;
In the example above:
If user specified nothing no grpcAction gets exposed.
If user specifies grpcAction it's used as is.
if user specifies grpcActionEnabled then grpcAction gets inferred.
I would like to propose an alternative for such cases, that is having a value like: <auto> to signify that the property is meant to be automatically configured. Of course for this change to be meaningfull it needs to be widely applied.
Thought's?
Implementation ideas
No response
The text was updated successfully, but these errors were encountered:
iocanel
changed the title
Convention for optioanlly inferring configuration values
Convention for optionally inferring configuration values
May 26, 2023
I experimented a little bit with it in order to find an elegant solution.
The goal of these experiments was to find a safe way of adopting conventions like the one described.
I didn't manage to find a proper solution but here are some things I've tried and the limitation of each approach.
I am putting my findings here for future reference.
For all the described approaches the end goal was to be able to dfined properties like this:
In other words instead of defining multiple properties at the same level to have some sort of optional fields under the same property to influence the behavior.
ConfigGroup + Converter
quarkus.kubernetes.readiness-probe.grpc-action is not recognized as a valid key.
EnumMap + Converter
EnumMap does not seem to be recognized as Map (I think this goes for all types extending Map, but not 100% sure).
Only String keys are supported.
Map + Converter
can't restrict keys.
quarkus.kubernetes.readiness-probe.grpc-action is not recognized as a valid key.
Description
Every know and then I come accross the case of having an Optional configuration property that the user is expected to provide and a secondary boolean flag that pretty much tells Quarkus to try and infer the value of the Optional property.
Recent example comming from: #33437:
In the example above:
grpcAction
it's used as is.grpcActionEnabled
thengrpcAction
gets inferred.I would like to propose an alternative for such cases, that is having a value like:
<auto>
to signify that the property is meant to be automatically configured. Of course for this change to be meaningfull it needs to be widely applied.Thought's?
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: