Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.215.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=TUwiR4ukuwTDpjI7T17MXyxHd5skBbbjEzquLxO7mnDLKlyydB7kDepjRZq9W3+ZqQ
         PIty47IyUvkXVST4xFE+FW2sbTybtp1BAFhyf0mIH13nCLM+OHV0Wf0TfjWy6dNFHHqF
         IvL79xHWIpEhFWk8H62/Ptn2MzNCfUBYO6+28=
MIME-Version: 1.0
In-Reply-To: 
 <E0F8F1147C0A1447A6C5B2C0BDE7970C0245405F@GAALPA1MSGUSR90.ITServices.sbc.com>
References: <AANLkTin-qKucQ6hTtnNaXqySADJHwkUoe02fFwzbH5bT@mail.gmail.com>
	<AANLkTik-0TLQnOxX76XFo3kfKW5Q+aZTCnhhFffmNn0W@mail.gmail.com>
	<AANLkTimG0e2uG+BcFTaSt5EWQV-UBwd0hmJ+Gp1=6i6y@mail.gmail.com>
	<AANLkTindOUQdW+FQi+uE56wZ8nHa918Osh3EfMmEbnE3@mail.gmail.com>
	<E0F8F1147C0A1447A6C5B2C0BDE7970C0245405F@GAALPA1MSGUSR90.ITServices.sbc.com>
Date: Mon, 28 Feb 2011 10:16:13 +0100
Message-ID: <AANLkTimzw3xx71d6hG9zobUi5QGCTCmiV1aj1QfwpDdQ@mail.gmail.com>
Subject: Re: same name sibling issuesq
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP)
<mg0855@att.com> wrote:
> I believe we experienced the same issue (in the moveFrom for a node) and
> filed a bug. =A0Please see https://issues.apache.org/jira/browse/JCR-2891

sorry, but i fail to see how JCR-2891 relates to the issue hand...

cheers
stefan

>
> This bug has been scheduled for 2.2.5 but I haven't heard when 2.2.5 is
> going to be released.
>
> -----Original Message-----
> From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> Sent: Sunday, February 27, 2011 1:02 PM
> To: users@jackrabbit.apache.org
> Subject: Re: same name sibling issuesq
>
>> the following logic applies:
>>
>> - find a matching 'named' child node definition (both name and
> required
>> type
>> =A0constraints must be satisfied)
>> - if none exists, the first residual child node definition that
> satisfies
>> =A0the required type constraint is chosen. the order of evaluation is
>> =A0undefined.
>>
>
> Just to clarify. =A0Are you saying that if two residual child node
> definitions
> are inherited from supertypes, then it's undefined which one get's
> applied?
> =A0Undefined in the specification, correct?
>
>
>>
>> see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
>> for the implementation.
>>
>
> And, here, you are referring me to see the actual jackrabbit
> implementation
> so I can peruse the logic myself, correct? =A0Thanks. =A0This is precisel=
y
> what
> I need.
>
> At this point, I'm fairly certain that I witnessed erratic behavior in
> Jackrabbit's evaluation of which rule to apply . . . I don't want to
> file a
> super vague ticket for this, as I know that vague tickets are annoying
> -- I
> see plenty of them myself, but I may not get time to investigate further
> . .
> . what do you recommend, should I file a ticket just so it's on record,
> or
> no?
>
>
>
>> WRT your use case i'd suggest to add residual property and child node
>> definitions to me:folder and remove the nt:unstructured supertype.
>>
>>
> Yes, I did something like this already. =A0I defined my own "unstructured=
"
> type and let my types inherit from that, thus taking all SNS out of the
> inheritance hierarchy.
>
>
>>
>>
>