[
https://issues.apache.org/jira/browse/JCR-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155861#comment-13155861
]
angela commented on JCR-3156:
-----------------------------
> Group#getMembers() does not pose a uniqueness constraint on the returned
> iterator.
come on.... that's the whole story about having the shortcut compared to
Group.getDeclaredMembers and having to
fetch the members of member-groups of the membergroups of the member-groups.
but if common sense is
not sufficient let's add this explicitly to the API contract.
> However, adding uniqueness will partially undo the gains from collecting
> group members lazily
> since the implementation would have to remember members in order to test for
> uniqueness.
where exactly is the gain if every single API consumer has to maintain that
list because the implementation
doesn't do it? i don't see the benefit and it would just lead to have that very
same code being written
multiple times... just thinking of our own usages of Group.getMembers() i know
at least 4 places where we
would need to add that filter. furthermore i think it is sufficient to remember
the IDs of the members that
have already been served.
> Group#getMembers may list inherited members multiple times
> ----------------------------------------------------------
>
> Key: JCR-3156
> URL: https://issues.apache.org/jira/browse/JCR-3156
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, security
> Affects Versions: 2.2, 2.3
> Reporter: angela
> Assignee: Michael Dürig
> Fix For: 2.4
>
> Attachments: JCR-3156.patch
>
>
> i just happen to detect the following regression that seems to be introduces
> quite a while ago:
> Group#getMembers is defined to return all group members including those
> inherited by another group being member of that group.
> Example:
> User t
> Group a : t is declared member
> Group b : t is declared member
> Group c : a, b are declared members
> The expected result of Group.getMembers was: a, b and t.
> What is currently happening is that t is included twice in the returned
> iterator.
> Quickly testing on jackrabbit 2.0 revealed that this used to work before...
> I didn't carefully check when that bug has been introduced but the the
> refactoring of the membership
> collections seems to be a possible culprit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
