jackrabbit-dev mailing list archives

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

    [ 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

       

Mime
View raw message