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
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:[email protected]] Sent: Sunday, February 27, 2011 1:02 PM To: [email protected] 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. > >
