[
https://issues.apache.org/jira/browse/JCR-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155831#comment-13155831
]
Michael Dürig commented on JCR-3156:
------------------------------------
Group#getMembers() does not pose a uniqueness constraint on the returned
iterator. So the current implementation is to the contract. Since uniqueness is
desirable I think we should also tighten that 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.
> 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
> 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
