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:36:08 GMT
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
>>>>
>>>
>>>
>>
>

Mime
View raw message