On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP) <[email protected]> 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:[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. > > >> >> >
