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> 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> 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> 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> wrote:
Hi,

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