Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 2 May 2013 09:38:16 +0000 (UTC)
From: "Julian Reschke (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12538314.1326459871538.259635.1367487496624@arcas>
In-Reply-To: <JIRA.12538314.1326459871538@arcas>
References: <JIRA.12538314.1326459871538@arcas>
Subject: [jira] [Comment Edited] (JCR-3207) Info map of NODE_MOVED event on
 node reordering is not according to spec
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185673#comment-13185673 ] 

Julian Reschke edited comment on JCR-3207 at 5/2/13 9:38 AM:
-------------------------------------------------------------

I can confirm that there's a compliance issue here. Unfortunately it's non-trivial to fix.

Events are generated based on the change information on NodeState. NodeState has the new ordering of the child elements, but doesn't know how the new ordering was obtained; therefore, given a node with children a and b the event info would be the same for:

 orderBefore("b", "a")

and

 orderBefore("a", null)

Furthermore, in order to compute the event EventStateCollection compares with the previous ordering. This is likely to fail for any save() operation that contains more than a single operation causing the ordering to change.

Feedback appreciated.  
 
                
      was (Author: reschke):
    I can confirm that there's a compliance issue here. Unfortunately it's non-trivial to fix.

Events are generated based on the change information on NodeState. NodeState has the new ordering of the child elements, but doesn't how the new ordering was obtained; therefore, given a node with children a and b the event info would be the same for:

 orderBefore("b", "a")

and

 orderBefore("a", null)

Furthemore, in order to compute the event EventStateCollection compares with the previous ordering. This is likely to fail for any save() operation that contains more than a single operation causing the ordering to change.

Feedback appreciated.  
 
                  
> Info map of NODE_MOVED event on node reordering is not according to spec
> ------------------------------------------------------------------------
>
>                 Key: JCR-3207
>                 URL: https://issues.apache.org/jira/browse/JCR-3207
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, observation
>    Affects Versions: 2.2.10, 2.3.5
>            Reporter: Unico Hommes
>            Assignee: Julian Reschke
>         Attachments: reordertest.patch
>
>
> According to JSR-283 "If the method that caused the NODE_MOVE event was a Node.orderBefore then the returned Map has keys srcChildRelPath and destChildRelPath with values corresponding to the parameters passed to the orderBefore method, as specified in the Javadoc." As the attached patch for the ReorderTest test case shows this is not the way jackrabbit behaves. Instead it looks like the value of the srcChildRelPath entry in the info map is really the destChildRelPath and destChildRelPath info entry seems to always be null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira