jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Date Wed, 30 Nov 2011 11:06:44 GMT

any missing ac related mixins are in fact added automatically
when using AccessControllManager#setPolicy. however, the import
of protected items is not triggered if the session importer
does not recognize the protected nature of the item to be imported.
this is determined by the effective node type of that parent
and that's why alex' proposal was correct: the root node must
have the mixin assigned because otherwise the policy node to
be imported is not recognized as such (the defining node type
in that case would be rep:root). should be fixed in rev. 1208362


On 11/25/11 3:47 PM, Alex Parvulescu wrote:
> Good question, I don't know what are the assumptions about the root node
> having some special acl properties.
> I've only seen the last 3 builds fail because of that. It apparently is
> a deeper issue. Maybe the proposed fix is not a good idea.
> alex
> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <jukka.zitting@gmail.com
> <mailto:jukka.zitting@gmail.com>> wrote:
>     Hi,
>     On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
>     <alex.parvulescu@gmail.com <mailto:alex.parvulescu@gmail.com>> wrote:
>      > After studying the neighboring tests, namely inspired by
>      > AccessControlImporterTest#testImportRepoACLAtTestNode
>      > I think the fix is as simple as adding the missing acl repo info
>     to the root
>      > node to #testImportRepoACLAtRoot:
>      >   target.addMixin("rep:RepoAccessControllable");
>     Sounds right, though I'm not sure if the importer from JCR-3152 should
>     take care of adding that mixin automatically.
>     I encountered the same issue before cutting the 2.3.4 release
>     candidate and came to the same conclusion that the
>     rep:RepoAccessControllable mixin is not present. Since the problem
>     doesn't occur consistently across builds I thought that it was due to
>     some test ordering issue. I fixed the test execution order in revision
>     1205866 which seemed to have solved the issue for me, but apparently
>     that was just a coincidence.
>     I wonder if we're still missing something. Why does the test pass
>     sometimes without the proposed fix?
>     BR,
>     Jukka Zitting

View raw message