ok, I kinda lost here any ideas how the root node can be sometimes protected?
http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected() http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2 Protected alex On Fri, Nov 25, 2011 at 5:30 PM, Alex Parvulescu <[email protected]>wrote: > > Sounds right, though I'm not sure if the importer from JCR-3152 should > take care of adding that mixin automatically. > > Good point, I went into that a bit, and it seems that the importer > (AccessControlImporter) *may* do that in the #start method (which never > gets called). > > The reason can be found under SessionImporter#startNode: > if (parent.getDefinition().isProtected()) > > Here parent is the root node, which seems to fail the test thus makin the > SessionImporter skip the vital #start call. > Indeed checking sImpl.getRootNode().getDefinition().isProtected() yields > false within the test context. > > alex > > On Fri, Nov 25, 2011 at 4:11 PM, Alex Parvulescu < > [email protected]> wrote: > >> I can't get it to pass anymore: >> >> By running >> rm -rf target; mvn -Dtest=AccessControlImporterTest clean test >> on jackrabbit-core (a fresh trunk checkout) >> >> It fails every time: >> >> -------- >> Running org.apache.jackrabbit.core.xml.AccessControlImporterTest >> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 14.925 >> sec <<< FAILURE! >> >> Results : >> >> Failed tests: >> testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest): >> expected:<1> but was:<0> >> >> Tests in error: >> >> testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessControlImporterTest): >> Authorizable for 'administrators' already exists: >> >> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0 >> -------- >> >> It is probably related to running the tests concurrently (JCR-3152 >> mentions that as well). >> >> alex >> >> On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu < >> [email protected]> 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]>wrote: >>> >>>> Hi, >>>> >>>> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu >>>> <[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 >>>> >>> >>> >> >
