You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Mark Struberg (JIRA)" <ji...@apache.org> on 2018/09/07 09:10:00 UTC

[jira] [Resolved] (DELTASPIKE-1335) allow atomic access to n different TypedResolver values

     [ https://issues.apache.org/jira/browse/DELTASPIKE-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Struberg resolved DELTASPIKE-1335.
---------------------------------------
    Resolution: Fixed

> allow atomic access to n different TypedResolver values
> -------------------------------------------------------
>
>                 Key: DELTASPIKE-1335
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1335
>             Project: DeltaSpike
>          Issue Type: New Feature
>          Components: Configuration
>    Affects Versions: 1.9.0
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>            Priority: Major
>             Fix For: 1.9.0
>
>
> If multiple related config values (TypedResolver) are accessed in the same request and the underlying config changes then we might up with a wild mixture of old and new values.
> An example would be to access some 'myapp.host' and 'myapp.port':
> The underlying values are 'oldserver' and '8080'.
> Now consider the following code:
> {code}
>  // get the current host value
> TypedResolver<String> hostCfg config.resolve("myapp.host");
> // and right inbetween the underlying values get 
> // changed to 'newserver' and port 8082
> // get the current port for the host
> TypedResolver<Integer> portCfg config.resolve("myapp.port");
> {code}
> In ths above code we would get the combination of 'oldserver' but with the new port 8081. And this will obviously blow up because that host+port combination doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)