jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: same name sibling issuesq
Date Mon, 28 Feb 2011 13:54:22 GMT
On Mon, Feb 28, 2011 at 2:34 PM, 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.

thanks for the background information!

>
> Matt
> p.s. I can definitely see how someone wouldn't see connection - as there might not be
one :)

OTOH i can't definitely rule out the possibility that there is a
connection ... ;)

cheers
stefan

>
> -----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
View raw message