jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: same name sibling issuesq
Date Mon, 28 Feb 2011 09:16:13 GMT
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.  Please 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
>>  constraints must be satisfied)
>> - if none exists, the first residual child node definition that
> satisfies
>>  the required type constraint is chosen. the order of evaluation is
>>  undefined.
>>
>
> Just to clarify.  Are you saying that if two residual child node
> definitions
> are inherited from supertypes, then it's undefined which one get's
> applied?
>  Undefined 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?  Thanks.  This is precisely
> 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.  I defined my own "unstructured"
> type and let my types inherit from that, thus taking all SNS out of the
> inheritance hierarchy.
>
>
>>
>>
>

Mime
View raw message