You mean it seems always *not* protected, right?

How can SessionImporter (line 316 startNode) [0] ever work then?

Is there something I'm missing?


[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 <mduerig@apache.org> 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.setRequiredPrimaryTypes(new Name[]{NameConstants.REP_ROOT});
   return def.build();



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/specs/jcr/2.0/3_Repository_Model.html# Protected


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.


   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:
       expected:<1> but was:<0>

       Tests in error:

       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).


       On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu
       <alex.parvulescu@gmail.com <mailto:alex.parvulescu@gmail.com>>


           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.


           On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting
           <jukka.zitting@gmail.com <mailto:jukka.zitting@gmail.com>>



               On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
               <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
               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?


               Jukka Zitting