[TAMAYA-354] Support atomic Configuration evaluation

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.3-incubating
• Fix Version/s: 0.4-incubating
• Component/s: API, Core, Extensions
• Assignee: Anatole Tresch
• Reporter: Anatole Tresch
• Created: 27/Sep/18 17:58
• Updated: 19/Nov/18 23:18
• Resolved: 19/Nov/18 23:18

Description

The current work in the Config JSR contains a nice feature, which allows to ensure access to configuration can be done atomically. This includes the following changes/additions:

• the PropertySource interface must be extended to allow registering of PropertySourceListeners to inform, when the PropertySource changes.
• The PropertySourceListener is a functional interface, which is called on change with the following data
  • the keys that were affected
  • the PropertySource instance

Given this extension it should be possible to define a ConfigurationQuery, that accesses multiple keys at once, where the Configuration system can guarantee a consistent state to be returned. This makes sense. e.g. consider port and host entries managed as separate config entries- Now when the property source changes between evaluation of the two entries, the returned result may be inconsistent. The ConfigurationQuery can be modelled as immutable object with a corresponding builder that allows to perform the following functions:

• ConfigurationQuery query = ConfigurationQuery.of(String... keys);
• ConfigurationQueryBuilder b = ConfigurationQuery.builder();
  ConfigurationQuery query = b.query("key")
  .queryWithDefault("key2", "stringDefault")
  .queryWithDefault("key2", myInstance)
  .build();
• As a result we could return another instance of Configuration, containing only the consistent values returned. The query itself could then be implemented as ConfigurationOperator, so there is no extension on the Configuration interface necessary. Unfortunately calls to getConfigurationContext(), toBuilder() (and maybe more) may throw UnupportedOperationException, or must be clearly defined, how they should behave.
  A better alternative IMO we could be to return the ConfigurationQuery passed, and add the corresponding accessor methods on it (get, getOrDefault etc) on it. The query itself can be implemented as ConfigurationQuery, so there is no extension on the Configuration interface necessary. We also can discuss to extract the corresponding accessor methods into a ConfigAccessor interface, which can be implemented by ConfigQuery and extended by Configuration.