On 5 Aug 2021, at 12:46, Mark Struberg <struberg@xxxxxxxxxx> wrote:
Hi Thomas et al!
Agree with Section "Config Source SPI" and good thoughts in "Content Type".
Ad "Eagerness": What do you mean with 'lazy sources'? ConfigSources added at runtime? Or the content (key/value) added/changed at runtime? Whenever you have something like a config served by a Database or a remote server then you will hit the later.
Lazy source: a source that cannot list the full set of provided options. E.g. you need to request a key to find out if it exists or not.
Ad "Mutability". If we do not support mutable config we loose a lot of use cases.
Such a solution cannot use any caching on Config implementation
Not really true. Look at DeltaSpike Config. The 'last modified' allows for rather good caching and fast cache eviction. Of course it's a bit tricky
What is last modified? Is that specific too DeltaSpike? If your source can provide such information, it is definitely good - but I do not see this in the current MP spec, which I use as the API/SPI I check against. Question would be if a source is capable of providing such information for all its configuration keys, or if that may be limited to a single key.
Yes the solution is also implemented in DeltaSpike Config. But I've also proposed this for the old JCP ConfigJSR.
It works by ConfigSources notifying the Config system whenever they detect a change in underlying configuration.
Of course that does not work well for 'lazy' sources. But while those do exist they are rather rare. Metric or some system monitor could issue a warning in this case. In other cases it works really fine.
My old proposal to read multiple of them in an atomic way is here:
The JavaDoc describes how it works.
This solution is mainly intended for programmatic/framework use like the CDI integration etc.
A user might rather use another solution Sebastian Daschner and I worked on: using access/resolve with a POJO type.
public class UrlConfig {
private String host;
private Integer port;
private String protocol;
...
}
TypedResolver<UrlConfig> urlCfg = config.resolve("myapp.archive.url").as(UrlConfig.class)
and for each usage you first do a
UrlConfig url = "">
All that with the following keys in your ConfigSources:
myapp.archive.url.host=somehost
myapp.archive.url.port=8084
myapp.archive.url.protocol=http
The system would also resolve and fill the POJO in an atomic way.
this also allows for inconsistent configuration (if you load two keys in sequence, each from a different version of underlying source)
The 'ConfigValue' solution did solve this but I understand that it's really too complicated. Resolving a POJO config could way easier be guaranteed to be atomic.
Resolving a pojo does not help, if config queries each source for each property. You would need to have a method on config source that provides more than one value “atomically"
See above. It works fine.
Mutability supported by config - config understands mutability options and each config source declares what kind of mutability it supports.
I'd need more info what you have in mind. First thought is that the evaluation rules might be a tad complex.
The rules are a bit complex - e.g. you know that the first source is mutable, second immutable etc. you would be able to optimise property lookup.
Still do not really have an image. Do you have an API draft how it would look like roughly? txs!
