Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <23278529.post@talk.nabble.com>
Date: Tue, 28 Apr 2009 07:42:51 -0700 (PDT)
From: Yoav  Landman <ylandman@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: Understanding mixins merge logic
In-Reply-To: <923C3657-7986-432A-A2AE-697724108524@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <23267598.post@talk.nabble.com>
 <923C3657-7986-432A-A2AE-697724108524@gmail.com>


Stefan Guggisberg wrote:
> 
> Hi yoav,
> 
> 
> 
> On 28.04.2009, at 01:51, Yoav  Landman <ylandman@gmail.com> wrote:
> 
>>
>> Hi,
>>
>> I am trying to understand the logic of merging mixing changes -
>> I see that the NodeStateMerger is failing a merge due do a  
>> difference in the
>> mixin type names. In practice, however, the content of the mixin type
>> namesets is identical between the overlayed state and the modified  
>> state
>> (same *names* references). But since the comparison of the 2 namesets
>> themselves is done by reference (NameSet does not override equals())  
>> and
>> since the *namesets* references are different the merge ends up with a
>> StaleItemStateException.
>>
>> My question is -
>> Shouldn't the comparison of the mixin type sets be done by content,  
>> not by
>> the references of the namesets themselves?
> 
> Agreed, seems to be a bug. I'll have a look tomorrow and let you know.
> 
Great. If it is so, I guess it might remove a lot of unnecessary
StaleItemStateExceptions.


>> The relevant comments in
>> NodeStateMerger say:
>> "the mixins have been modified but by just looking at the diff we  
>> can't
>> determine where the change happened since the diffs of either  
>> removing a
>> mixin from the overlayed or adding a mixin to the transient state  
>> would look
>> identical..."
>> I am trying to understand this and how it applies to the current  
>> behavior,
>> but can't. Could someone shed some light on it?
> 
> I guess the namesets are copied-on-write. The assumption therefore is  
> that  non-equal nameset references mean that they've been modified.  
> I'll have a look.
> 
> Cheers
> Stefan
> 
> 
In my case I have 2 states with 2 different nameset references. Each nameset
contains 2 instances of o.a.j.spi.commons.name.NameFactoryImpl$NameImpl:
{http://www.jcp.org/jcr/mix/1.0}referenceable, and
{http://www.jcp.org/jcr/mix/1.0}lockable
Those 2 name instances are identical (same reference) between the 2
namesets, yet the namesets are considered different.


>>
>>
>> Thanks,
>>
>> Yoav
>> -- 
>> View this message in context:
>> http://www.nabble.com/Understanding-mixins-merge-logic-tp23267598p23267598.html
>> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Understanding-mixins-merge-logic-tp23267598p23278529.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.