jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Date Fri, 25 Nov 2011 18:21:38 GMT

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
> <alex.parvulescu@gmail.com <mailto:alex.parvulescu@gmail.com>> 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
>     <alex.parvulescu@gmail.com <mailto:alex.parvulescu@gmail.com>> 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
>         <alex.parvulescu@gmail.com <mailto:alex.parvulescu@gmail.com>>
>         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
>
>
>
>
>

Mime
View raw message