sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Janaki Ratnakar Bhagwath (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 06:22:00 GMT

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

Janaki Ratnakar Bhagwath updated SLING-8296:
--------------------------------------------
    Description: 
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 create twice
and removes 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}
 

  was:
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 childPositionInCandidate List is actually
not -1, this logic is not triggered and the first block executes, which adds create twice
and removes 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}
 


> 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
>            Reporter: Janaki Ratnakar Bhagwath
>            Priority: Major
>
> 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 create twice
and removes 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