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