[jira] [Comment Edited] (SLING-4915) Order of sub-nodes is not maintained in case of a merge

["Konrad Windszus (JIRA)" <ji...@apache.org>]

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

Konrad Windszus edited comment on SLING-4915 at 2/10/16 1:20 PM:
-----------------------------------------------------------------

[~radu.cotescu] Which order should be taken in case  {{p2}} would not redefine all the children from {{p1}} but only few of them? Which order should be used then? Just take the following example 
{code}
/libs/p1/components/c1
  node1
  node2
  node3
/libs/p2/components/c1 (sling:resourceSuperType=/libs/p1/components/c1)
  node4
  node2
  node3
{code}

The current rule is:
Always first all children of the underlying resource (in the order defined by the underlying resource) then all new children only defined by the overlaying resource. That can only be changed with the {{sling:orderBefore}}.


was (Author: kwin):
[~radu.cotescu] Which order should be taken in case  {{p2}} would not redefine all the children from {{p1}} but only few of them? Which order should be used then? Just take the following example 
{code}
/libs/p1/components/c1
  node1
  node2
  node3
/libs/p2/components/c1 (sling:resourceSuperType=/libs/p1/components/c1)
  node4
  node2
  node3
{code}

> Order of sub-nodes is not maintained in case of a merge
> -------------------------------------------------------
>
>                 Key: SLING-4915
>                 URL: https://issues.apache.org/jira/browse/SLING-4915
>             Project: Sling
>          Issue Type: Bug
>          Components: ResourceResolver
>    Affects Versions: Resource Merger 1.2.10
>            Reporter: Radu Cotescu
>            Priority: Minor
>             Fix For: Resource Merger 1.2.12
>
>
> Given two content structures that should be merged by the Resource Merger, if the second tree contains all the sub-nodes of the first tree, a new node added in the second tree will always be added towards the end, irrespective of its position in the sub-node tree.
> Example:
> {noformat}
> /libs/p1/components/c1
>   node1
>   node2
>   node3
> /libs/p2/components/c1 (sling:resourceSuperType=/libs/p1/components/c1)
>   node1
>   node4
>   node2
>   node3
> {noformat}
> When iterating over the child resources of {{/libs/p2/components/c1}}, {{node4}} will be the last child in the iteration instead of the second.
> The workaround is to not define the redundant nodes and add the {{sling:orderBefore}} property on {{node4}}, however this should be handled by default by the merger.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)