Anatole Tresch created TAMAYA-354:
-------------------------------------
Summary: Support atomic Configuration evaluation
Key: TAMAYA-354
URL: https://issues.apache.org/jira/browse/TAMAYA-354
Project: Tamaya
Issue Type: Improvement
Components: API, Core, Extensions
Affects Versions: 0.3-incubating
Reporter: Anatole Tresch
Assignee: Anatole Tresch
Fix For: 0.4-incubating
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_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
