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 Sun, 27 Feb 2011 20:07:50 GMT
On Sun, Feb 27, 2011 at 7:02 PM, ChadDavis <chadmichaeldavis@gmail.com> wrote:
>> 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?

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?

correct. you can view the source code e.g. here:

http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/nodetype/EffectiveNodeType.java?view=markup

the relevant code starts at line 692.

> 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?

to be honest, if a ticket is rather vague chances that someone will
invest time to investigate are usually low.

the scenario that you described in this thread is IMO as expected.

OTOH, if you're pretty sure you found a bug it might still be worth
reporting it.

>
>
>
>> 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.

excellent :)

cheers
stefan

>
>
>>
>>
>

Mime
View raw message