Hi, You mean it seems always *not* protected, right? def.setProtected(false);
How can SessionImporter (line 316 startNode) [0] ever work then? Is there something I'm missing? alex [0] http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/xml/SessionImporter.java On Fri, Nov 25, 2011 at 7:21 PM, Michael Dürig <[email protected]> wrote: > > It seems to be always protected: > > private static QNodeDefinition createRootNodeDef() { > QNodeDefinitionBuilder def = new QNodeDefinitionBuilder(); > > // FIXME need a fake declaring node type: > // rep:root is not quite correct but better than a non-existing node > type > def.setDeclaringNodeType(**NameConstants.REP_ROOT); > def.setRequiredPrimaryTypes(**new Name[]{NameConstants.REP_ROOT}**); > def.setDefaultPrimaryType(**NameConstants.REP_ROOT); > def.setMandatory(true); > def.setProtected(false); > def.setOnParentVersion(**OnParentVersionAction.VERSION)**; > def.setAllowsSameNameSiblings(**false); > def.setAutoCreated(true); > return def.build(); > } > > NodeTypeRegistry:1808 > > Michael > > > On 25.11.11 16:36, Alex Parvulescu wrote: > >> 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/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<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] >> <mailto:alex.parvulescu@gmail.**com<[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] >> <mailto:alex.parvulescu@gmail.**com<[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] >> <mailto:alex.parvulescu@gmail.**com<[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] >> <mailto:jukka.zitting@gmail.**com<[email protected]> >> >> >> >> wrote: >> >> Hi, >> >> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu >> <[email protected] >> >> <mailto:alex.parvulescu@gmail.**com<[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 >> >> >> >> >> >>
