Hi Brian,
Thanks for making a fantastic config library. We (at Pinterest) have been using it extensively to set up our configuration infrastructure for our streaming applications.
One common pattern we have seen is that we often set up configs in the following manner:
code.java
interface ConfigIface {
@Config("c")
String getConfigInternal();
default String getConfig() {
if ("auto".equalsIgnoreCase(getConfigInternal())) {
return "some-value-that-we-set-in-just-1-location-instead-of-50-configs-that-we-can-evolve";
}
return getConfigInternal();
}
}
config.properties:
my.friendly.prefix.c=auto
The reason we do it this way is so that client teams know that the config actually exists (and can be overridden by them) but
The proposal is supporting this via a new annotation: @AutoDefault to make code like this:
interface ConfigIface {
@Config("c")
@AutoDefault("some-value-that-we-set-in-just-1-location-instead-of-50-configs-that-we-can-evolve")
String getConfig();
}
config.properties:
my.friendly.prefix.c=auto
The difference with @Default is that the key is actually required in the config (so the configs all look the same and it's super clear where the framework is setting a value and where a user is setting a value). This is so common that we'd like to upstream it into the code so that we don't have to keep doing this.
Would you be open to accepting a pull request that implements this functionality?
It's a short change (10s of lines of code) - PR to follow.
Hi Brian,
Thanks for making a fantastic config library. We (at Pinterest) have been using it extensively to set up our configuration infrastructure for our streaming applications.
One common pattern we have seen is that we often set up configs in the following manner:
The reason we do it this way is so that client teams know that the config actually exists (and can be overridden by them) but
The proposal is supporting this via a new annotation:
@AutoDefaultto make code like this:The difference with
@Defaultis that the key is actually required in the config (so the configs all look the same and it's super clear where the framework is setting a value and where a user is setting a value). This is so common that we'd like to upstream it into the code so that we don't have to keep doing this.Would you be open to accepting a pull request that implements this functionality?
It's a short change (10s of lines of code) - PR to follow.