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 15:11:00 GMT
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