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