hi 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
regards angela 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 <[email protected] <mailto:[email protected]>> wrote: Hi, On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu <[email protected] <mailto:[email protected]>> 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
