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 Mon, 28 Nov 2011 09:09:40 GMT
Hi,

You mean it seems always *not* protected, right?
   def.setProtected(false);

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

Is there something I'm missing?

alex

[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.setDeclaringNodeType(**NameConstants.REP_ROOT);
>    def.setRequiredPrimaryTypes(**new Name[]{NameConstants.REP_ROOT}**);
>    def.setDefaultPrimaryType(**NameConstants.REP_ROOT);
>    def.setMandatory(true);
>    def.setProtected(false);
>    def.setOnParentVersion(**OnParentVersionAction.VERSION)**;
>    def.setAllowsSameNameSiblings(**false);
>    def.setAutoCreated(true);
>    return def.build();
> }
>
> NodeTypeRegistry:1808
>
> Michael
>
>
> 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/maven/**javax.jcr/javadocs/jcr-2.0/**
>> javax/jcr/nodetype/**ItemDefinition.html#**isProtected()<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<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 <mailto:alex.parvulescu@gmail.**com<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 <mailto:alex.parvulescu@gmail.**com<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 <mailto:alex.parvulescu@gmail.**com<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 <mailto:jukka.zitting@gmail.**com<jukka.zitting@gmail.com>
>> >>
>>
>>            wrote:
>>
>>                Hi,
>>
>>                On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
>>                <alex.parvulescu@gmail.com
>>                <mailto:alex.parvulescu@gmail.**com<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