jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOODWIN, MATTHEW (ATTCORP)" <mg0...@att.com>
Subject RE: same name sibling issuesq
Date Mon, 28 Feb 2011 13:34:25 GMT
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.

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...


> 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.

View raw message