sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SLING-8296) MergingResourceProvider purges the last item if existing item is overlaid and has sling:orderBefore property set
Date Wed, 27 Feb 2019 07:58:00 GMT

     [ https://issues.apache.org/jira/browse/SLING-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Carsten Ziegeler updated SLING-8296:
------------------------------------
    Affects Version/s: Resource Merger 1.3.8

> MergingResourceProvider purges the last item if existing item is overlaid and has sling:orderBefore
property set
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: SLING-8296
>                 URL: https://issues.apache.org/jira/browse/SLING-8296
>             Project: Sling
>          Issue Type: Bug
>          Components: ResourceResolver
>    Affects Versions: Resource Merger 1.3.8
>            Reporter: Janaki Ratnakar Bhagwath
>            Priority: Major
>             Fix For: Resource Merger 1.3.10
>
>
> The MergingResourceProvider has a logic which tends to purge the last element on the
merged list if one of the overlaid nodes is from the original node and has a "sling:orderBefore" property.
> Example:
> */libs resource has*
> create, edit, delete, update, rollout
> */apps overlaid resource has*
> move, create (sling:orderBefore=edit)
> _The_ orderBefore _property in the /apps resource is added to ensure that the overlaid
node is not pushed to the end._
> *Excepted Merged Resource /mnt/overlay*
> create, edit, delete, update, rollout, move
> *Actual Response*
> create, edit, delete, update, rollout
> This is due to a logical issue in the following lines of code in MergingResourceProvider. 
> When the _sling:_orderBefore is set, even though childPositionInCandidateList is actually
not -1, this logic is not triggered and the first block executes, which adds the overlaid
existing node create twice and removes the last element move in the previous example.
> {code:java}
> // either reorder because of explicit reording property
> if (orderBeforeIndex > -1) {
>     candidates.add(orderBeforeIndex, holder);
>     candidates.remove(candidates.size() - 1);
> } else {
>     // or reorder because overlaid resource has a different order
>     if (childPositionInCandidateList != -1 && previousChildPositionInCandidateList
!= -1) {
>         candidates.remove(childPositionInCandidateList);
>         if (childPositionInCandidateList < previousChildPositionInCandidateList) {
>             previousChildPositionInCandidateList--;
>         }
>         if(previousChildPositionInCandidateList+1 > candidates.size()){
>             candidates.add(holder);
>         } else {
>             candidates.add(previousChildPositionInCandidateList + 1, holder);
>         }
>         previousChildPositionInCandidateList++;
>     }
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message