[
https://issues.apache.org/jira/browse/TAMAYA-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16691059#comment-16691059
]
ASF subversion and git services commented on TAMAYA-354:
--------------------------------------------------------
Commit e190b34f24fc45f16c14442db81ae8f6c72d34dc in
incubator-tamaya-extensions's branch refs/heads/master from [~anatole]
[
https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya-extensions.git;h=e190b34
]
TAMAYA-354 Support atomic configuration, similar to config JSR.
> 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
> Priority: Major
> 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)
