-
Notifications
You must be signed in to change notification settings - Fork 11
implement the ability to plugin fallback values #236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
8fe989b
58e028e
4e2c2cb
31e6d3c
d828b9a
d00ca80
84ceafa
8da4c81
303bd7d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| package io.avaje.config; | ||
|
|
||
| import io.avaje.config.Configuration.Entry; | ||
|
|
||
| import java.util.Optional; | ||
|
|
||
| /** | ||
| * Implementations of this class are able to define a fallback value when there is no | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am wondering if the name Even if this name is retained as-is, the class comments would be good to update so that they describe the role of the SPI interface. |
||
| * value available for a configuration key. | ||
| * <p> | ||
| * The default implementation uses System Properties and Environment variables. | ||
| */ | ||
| public interface ConfigurationFallback extends ConfigExtension { | ||
|
|
||
| /** | ||
| * Provides the ability to override the value that is going to be set. | ||
| * <p> | ||
| * By default, this just returns the value that is passed in and does not | ||
| * override the value. | ||
| * | ||
| * @param key The property key | ||
| * @param value The value that can be overridden by the returned value | ||
| * @param source The source of the key value pair | ||
| */ | ||
| default Entry overrideValue(String key, String value, String source) { | ||
| return Entry.of(value, source); | ||
| } | ||
|
|
||
| /** | ||
| * Return a value for the supplied key or {@code null} if there is no value. | ||
| * | ||
| * @param key The configuration key to get a fallback value for. | ||
| */ | ||
| default Optional<Entry> fallbackValue(String key) { | ||
| return Optional.empty(); | ||
| } | ||
|
|
||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably a good idea to either fail if there are two instances of
ConfigurationFallbackconfigured; otherwise the behaviour may become unpredictable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I have a use case where for Tests, it would be useful to use an alternative ConfigurationFallback.
In this case the test configuration would have values like
ssm://test/myapp/some_key_of_secret... and if a value had that special prefix it would load the value from the AWS secret store. You need aws single signon to be able to do this of course. This is to assist 2 scenarios which is (1) running locally against Dev/Test and (2) Integration tests
I think the override feature would actually support this and ideally this is only done for Testing, so the override implementation is only in maven test scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rbygrave ; I think it may be good to look into throwing in this scenario because otherwise the behaviour could be confusing and difficult to track down.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in this case there would be an instance of
ConfigurationFallbackfrom the main classpath and an instance from the test classpath? It may be worth logging tostderr(at least) that this is happening because in other situation a clash will be hard to comprehend.