[jira] [Commented] (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:comment-tabpanel=16501652#comment-16501652
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit bb5ee1e699dbaab8e18af3659a71d72166bd67cc in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=bb5ee1e ]
DELTASPIKE-1335 provide helper methods to diff configs
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16456911#comment-16456911
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit 6e7005fe35cf0a608e84ee8e7534ba6510e9b838 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=6e7005f ]
DELTASPIKE-1335 add onChange callback and improve docs for ConfigSnapshot logic
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16445642#comment-16445642
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit aabbc879e389bfa3538cbdfa52a19fbfae904616 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=aabbc87 ]
DELTASPIKE-1335 move access to configured value to TppedResolver
Feedback from Jeff Mesnil and Tomas Langer.
It will be easier to understand if the access to the effective value
is done via TypedResolver and ConfigSnapshot is merely a value holder.
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16428066#comment-16428066
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit 9c125bd010de5bcd60f66ba2c3b0c019f108a5e0 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=9c125bd ]
DELTASPIKE-1335 rename ConfigTransaction to ConfigSnapshot
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16426814#comment-16426814
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit a6296773d14db2339289179cf80ddb0339519229 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a629677 ]
DELTASPIKE-1335 improve docs and tst handling
hacked together with Alexander Falb (elexx)
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16426812#comment-16426812
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit fdd1e3dcd9a12ceed831dd7460492b6dd788721c in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=fdd1e3d ]
DELTASPIKE-1335 proposal for atomic config access
crafted together with Manfred Huber
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16426815#comment-16426815
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit 0ec1c1e5bca85141ddbe164d50743c13b572e73b in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=0ec1c1e ]
DELTASPIKE-1335 DELTASPIKE-1277 fix reportChangeListener
Also implement the config change callback in the new
ConfigurableTestConfigSource
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16426813#comment-16426813
]
ASF subversion and git services commented on DELTASPIKE-1335:
-
Commit a101bab996d6cfad8369dc96626bb7d016318351 in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=a101bab ]
DELTASPIKE-1335 atomic access to configured values
> 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 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 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)
[jira] [Commented] (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:comment-tabpanel=16425772#comment-16425772
]
Mark Struberg commented on DELTASPIKE-1335:
---
pushed a proposed new API for solving this issue to a feature branch
https://github.com/struberg/deltaspike/tree/DELTASPIKE-1335
The following JavaDoc describes the interesting parts:
https://github.com/struberg/deltaspike/blob/DELTASPIKE-1335/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/Config.java#L45
wdyt?
> 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 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 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)
