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 2013/10/30 12:00:26 UTC

[jira] [Reopened] (SLING-3164) Clarify and deprecate ClusterView.getId

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

Stefan Egli reopened SLING-3164:
--------------------------------


As the further discussion in [0] evolved, it turned out that ClusterView.getId should not be deprecated but instead be improved and made more stable. Hence this ticket is reopen to adjust the javadoc of ClusterView.getId. There is a separate ticket, SLING-3195, about the improvement/stabilization of the id.

[0] - http://markmail.org/message/kf3pydso7eruiwfg

> Clarify and deprecate ClusterView.getId
> ---------------------------------------
>
>                 Key: SLING-3164
>                 URL: https://issues.apache.org/jira/browse/SLING-3164
>             Project: Sling
>          Issue Type: Bug
>    Affects Versions: Discovery API 1.0.0
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>             Fix For: Discovery API 1.0.2
>
>
> As discussed on the list (at [0]) the ClusterView.getId() is currently unspecific about whether the id is stable/persistent or not. The current implementation of it is not stable and returns a new id with every changing cluster view. Without assumptions on the underlying implementation details it is not trivial to provide a stable id. This contrasts to the slingId of an InstanceDescription - which is guaranteed to be stable. A cluster can reshape and join another cluster, hence a cluster id is not trivial to be stable.
> The suggestion is to clarify the unstable nature of that id in its javadoc and marking it as deprecated - since there is no use for an unstable id really.
> --
> [0] - http://markmail.org/message/kf3pydso7eruiwfg



--
This message was sent by Atlassian JIRA
(v6.1#6144)