[jira] [Comment Edited] (TAMAYA-354) Support atomic Configuration evaluation

["Anatole Tresch (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAMAYA-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690063#comment-16690063 ] 

Anatole Tresch edited comment on TAMAYA-354 at 11/16/18 10:11 PM:
------------------------------------------------------------------

My current proposal is to add a snapshot functionality similar as defined by JSR382 in the API:

{{  ConfigurationSnapshot fullSnapshot = config.getConfigurationSnapshot();}}
 {{  ConfigurationSnapshot constrainedSnapshot = config.getConfigurationSnapshot("key1", key2");}}

Hereby

{{  ConfigurationSnapshot extends Configuration}}

To ensure the data read from a snapshot is consistent, the PropertySource gets additional methods (also similar to the JSR):

   String getVersion();
    ChangeSupport getChangeSupport();

where

{{  enum ChangeSupport{}}
     IMMUTABLE, SUPPORTED, UNSUPPORTED}}
    }

 


was (Author: anatole):
My current proposal is to add a snapshot functionality similar as defined by JSR382 in the API:

{{  ConfigurationSnapshot fullSnapshot = config.getConfigurationSnapshot();}}
{{  ConfigurationSnapshot constrainedSnapshot = config.getConfigurationSnapshot("key1", key2");}}

Hereby

{{  ConfigurationSnapshot extends Configuration}}

To ensure the data read from a snapshot is consistent, the PropertySource gets additional methods (also similar to the JSR):

   String getVersion();
   ChangeSupport getChangeSupport();

where

{{  enum ChangeSupport{}}
{{     IMMUTABLE, SUPPORTED, UNSUPPORTED}}
{{  }}}

 

> 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)