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 Mon, 28 Feb 2011 13:41:19 GMT
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)
<mg0855@att.com>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:stefan.guggisberg@gmail.com]
> Sent: Monday, February 28, 2011 4:16 AM
> To: users@jackrabbit.apache.org
> Subject: Re: same name sibling issuesq
>
> On Sun, Feb 27, 2011 at 8:32 PM, GOODWIN, MATTHEW (ATTCORP)
> <mg0855@att.com> 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:chadmichaeldavis@gmail.com]
> > Sent: Sunday, February 27, 2011 1:02 PM
> > To: users@jackrabbit.apache.org
> > 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.
> >
> >
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message