Access to config value metadata using a ConfigValue wrapper

[starksm64]

As far as I can see from all of the current proposals, the Config.get(...) is returning a resolved value that has thrown away any notion of the source and conversion information. Wouldn't it be better for the base return value from Config.get(...) to be a ConfigValue that maintains the information along the lines of:

public interface ConfigValue {

/**
 * Return the resolved property value with the specified type for the
 * specified property name
 * 
 * @param <T>
 *             the property type
 * @param propertyType
 *             The type into which the resolve property value should get converted
 * @return the resolved property value as an Optional of the requested type.
 */
<T> Optional<T> getValue(Class<T> propertyType);

/**
 * Get configuration value propertyName.
 *
 *             
 * @return The configuration propertyName.
 *
 */
String getName();

/**
 * @return all currently registered {@link ConfigSource}s for this value
 */
Iterable<ConfigSource> getConfigSources();

...

[Emily-Jiang]

Can you describe your user case? You can obtain a list of config sources from config in an ordered fashion. If you want to find out the serving config source for a particular config, if you search search the config source and the first config source found will be the config owner. I don't see how frequent you need to retrieve its source. Therefore, I don't think it is necessary to return a wrapper again.

[starksm64]

The use case is that in a management interface that is allowing runtime editing/viewing of the existing configuration, one can see an annotation for the source of the current value. Although this does not have to happen from the value level itself, it is simpler, and it lends itself as the point for extensions we have discussed down the road such as change listeners, etc.

[struberg]

Hi Scott!
ConfigSources are not intended to be modified by a user. Each ConfigSource can of course provide it's very own way to change configured values.
And for just looking up which ConfigSource contains a value you can also easily iterate over the ConfigSources and ask each of them on it's own.
Any change-listener approach would need a much deeper integrated functionality imo.

The reason for the ConfigValue is to allow functionality which needs to keep some state. E.g. the last load time, previously loaded values, etc.

There are 4 features I like to get covered in our Config system. We do not need to implement all of them now, but they are all useful:

• variable replacement, e.g. myprj.url=http://${myprj.archive.server}/docs
• dynamic reloading / caching: val.cacheFor(5, TimeUnit.MINUTES);
• postfix based lookupchains: e.g. myprj.url.production vs myprj.url.development vs myprj.url (default value). 2 ways needed: a.) lookup based on string postfix, b.) based on another config entry.
• List handling: comma separated values might get picked up as List

Happy to discuss those in our next hangout.

[keilw]

I don't think Scott was talking about a ConfigSource but more values in a Config element.
Even a bit more specialized than MP Config, but many (especially @starksm64 ) will know JSR 107 and e.g. the https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/configuration/MutableConfiguration.java. It allows to modify configuration elements. Whether you do it that way or via a complete "clone" for editing the configuration, there may be multiple ways (each has benefits and penalties, e.g. memory etc.) but in a dynamic "Cloud" or Microservice environment you don't just have the good old static files you once write and then never touch after starting your service. Therefore some users maybe with a certain role (that's where security and identiy efforts come into play) must be allowed to change config on particular nodes or services. Others may only consume the read only config.

[starksm64]

Right, I'm talking about a ConfigValue as returned from a Config. A default method on Config could provide the source for a given property, but it just seems like there are a number of uses for having a value wrapper to build features on. I have asked Heiko to comment on this as well as he is much deeper into our config and management requirements.

[heiko-braun]

I think we shouldn't get caught up on the mutation of config values, which I think isn't @starksm64 primary use case. What he seems to be proposing instead is an intermediary to connect to related use cases to the layer of config sources and values.

One of these related cases may be to access to pure meta data (origin of a config value) or listening for change events amongst other things.

Personally I think there is a lot of value for such an intermediary being a first class citizen. In particular when thinking about cases that we don't cover in the first iteration, but that might become relevant in the future.

As an alternative to Scott's proposal I can think of an a separate API to get hold of these intermediaries, rather then attaching it to the config value directly. This would keep access to configuration values like in the current proposal, but also support future use cases leveraging the intermediary objects.

[keilw]

Some sort of DTO maybe, at least that's what the types of services here in current banking gig use (increasingly based on either Microservice or SCS pattern)

[OndroMih]

First I wanted to oppose this suggestion, but I realized that the getValue method already returns Optional, which already adds a layer of indirection. A problem with optional is that is a final class, and therefore it cannot be enhanced in the future. If you return ConfigValue and copy over all methods from Optional instead, we can easily add new methods later without breaking changes. And no additional layer of redirection is added on top of the current proposal.

And with further additions, I'm not speaking only about metadata, but also about possibility to add better support for programming constructs or copy the methods planned for Java 9 and have it already with Java 8.
ConfigValue can later easily extend from a common custom Optional class/interface, which is not possible with Java SE Optional (which is a final class)

[struberg]

@starksm64 Emily and I are currently walking through the open issues. Are you happy with the current ability to implement your use case or do you have additional needs?

txs and LieGrue,
Emily and strub

[starksm64]

It seems like a few people are interested in an ability to obtain a single DTO representation of the composed value of a property from a Config. If it is not the actual return value, is there an api to access such a value?

[struberg]

@starksm64 you mean something like

Map<String, String> Config.filter("org.mycomp.somepkg") 

?

If not, can you share a code sample of how you envision it to work? /cc @heiko-braun

[starksm64]

I was thinking something like this, which the sourceValues ordered by priority from highest to lowest:

List sourceValues = Config.filter("org.mycomp.somepkg")
class ConfigValue {
Optional<?> getValue();
ConfigSource getSource();
}

[Emily-Jiang]

@starksm64 Can you attend the hangout on 27th April to discuss this further?

[starksm64]

Yes.

[Emily-Jiang]

Thanks @starksm64 ! Talk to you then.

[Emily-Jiang]

@starksm64 and I met on 27th April and discussed this further. This sounds a good feature for config 1.1. e.g. add one more method to config.getWrappedValue(...) to return a wrapped value, which can trace back to the config source that provides the config value.

[OndroMih]

It seems like this proposal also suggest to have a ConfigValue wrapper, although for a different usecase: #91

[Emily-Jiang]

I think it is good idea to introduce ConfigValue as a wrapper to contain a few methods to perform variable replacement, default, which configsource the value comes from etc.

[dmlloyd]

In other words, a config accessor?

Also, does this really merit a whole label? Will we be having labels for every implementation idea now?

[Emily-Jiang]

Use case:
As a developer, I would like to know where my config value is from.

[Emily-Jiang]

Close this issue as the PR from @radcortez has been merged.