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/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:[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:[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:[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:[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
