jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Parvulescu <alex.parvule...@gmail.com>
Subject Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Date Fri, 25 Nov 2011 16:30:24 GMT
> 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
>>>
>>
>>
>

Mime
View raw message