[
https://issues.apache.org/jira/browse/SLING-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-5258.
--------------------------------
Resolution: Fixed
Adjusted EstablishedClusterView appropriately (it now sets the
localClusterSyncTokenId using the votingId) - plus added a new test that
verifies this works. As mentioned, this builds ontop of SLING-5256.
rev: 1712784
> ensure a new establishedView (with different syncTokenId) always triggers a
> TOPOLOGY_CHANGED
> --------------------------------------------------------------------------------------------
>
> Key: SLING-5258
> URL: https://issues.apache.org/jira/browse/SLING-5258
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: Discovery Impl 1.2.0
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Fix For: Discovery Impl 1.2.2
>
>
> With SLING-5256 the unerlying mechanisms in ViewStateManager etc ensure that
> when a topology is passed to {{handleNewView}} that contains the very same
> instances/properties but differs only in the localClusterSyncId (which is the
> resource name of the voting in the discovery.impl case), that this then
> properly generates a TOPOLOGY_CHANGED and a TOPOLOGY_CHANGING first (if
> required).
> SLING-5058 was suggesting a different approach to achieving the same: to add
> a {{viewCnt}}. Now SLING-5058 really becomes obsolete with SLING-5256 - but
> that should be properly verified first - hence this ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
