jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ChadDavis <chadmichaelda...@gmail.com>
Subject Re: same name sibling issuesq
Date Sun, 27 Feb 2011 18:02:06 GMT
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message