[SLING-4915] Order of sub-nodes is not maintained in case of a merge

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: Resource Merger 1.2.10
• Fix Version/s: Resource Merger 1.3.2
• Component/s: ResourceResolver
• Assignee: Konrad Windszus
• Reporter: Radu Cotescu
• Created: 29/Jul/15 10:09
• Updated: 14/Jun/17 11:24
• Resolved: 12/Feb/16 10:58

Description

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:

/libs/p1/components/c1
  node1
  node2
  node3
/libs/p2/components/c1 (sling:resourceSuperType=/libs/p1/components/c1)
  node1
  node4
  node2
  node3

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.

Issue Links

• breaks: SLING-6956 Sling Resource Merger: Resources being overlaid are always listed at the end of the list