jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3156) Group#getMembers may list inherited members multiple times
Date Wed, 23 Nov 2011 13:33:39 GMT

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


View raw message