I didn't immediately see a connection either. On the other hand, as vague as I am, currently, about what is causing it, connections could be fairly obscure.
On Mon, Feb 28, 2011 at 6:34 AM, GOODWIN, MATTHEW (ATTCORP) <[email protected]>wrote: > It actually may not at all but I couldn't tell for sure because there was > no stack trace of the ItemExistsException. We ran into the situation (as > outlined in the JIRA I referenced) where we would get that exception for SNS > but in our case we were getting the exception when we felt we shouldn't have > and for us it happened correctly somewhat sporadically (the original email > indicated this as well). In our case this was because when things would fail > it would be because sometimes the object (not totally sure how objects were > instantiated) would have the same object id's and our node was specified as > not allowing SNS and would fail. Might not be the same situation but I > thought since the ticket had a patch on it it might be a quick try to see if > it solved their problems. > > Matt > p.s. I can definitely see how someone wouldn't see connection - as there > might not be one :) > > -----Original Message----- > From: Stefan Guggisberg [mailto:[email protected]] > Sent: Monday, February 28, 2011 4:16 AM > To: [email protected] > Subject: Re: same name sibling issuesq > > 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. > > > > > >> > >> > > >
