You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2015/11/16 16:00:16 UTC

[jira] [Closed] (SLING-5258) ensure a new establishedView (with different syncTokenId) always triggers a TOPOLOGY_CHANGED

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

Stefan Egli closed SLING-5258.
------------------------------

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