[jira] [Updated] (SLING-3973) ResourceProviderEntry Should Poll All Viable ModifyingResourceProviders During creation and deletion

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

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

Carsten Ziegeler updated SLING-3973:
------------------------------------
    Fix Version/s: Resource Resolver 1.2.2

> ResourceProviderEntry Should Poll All Viable ModifyingResourceProviders During creation and deletion
> ----------------------------------------------------------------------------------------------------
>
>                 Key: SLING-3973
>                 URL: https://issues.apache.org/jira/browse/SLING-3973
>             Project: Sling
>          Issue Type: Improvement
>          Components: ResourceResolver
>            Reporter: Paul Michelotti
>            Assignee: Carsten Ziegeler
>              Labels: patch
>             Fix For: Resource Resolver 1.2.2
>
>         Attachments: traverse-all-viable-modifying-resource-providers.diff
>
>
> Currently the ResourceProviderEntry, during creation or deletion of a resource, will send the creation or deletion request to the first viable ModifyingResourceProvider.  This is problematic if multiple ModifyingResourceProviders may be viable for a particular path.  Consider the following situation:
> I create a Resource Provider which listens to /content such that it can participate in resource listing calls on that path.  It however does not necessarily handle all resources under /content, the root JcrResourceProvider is also expected to handle some resources under that path.  This works fine for the various get methods, however for modification, the custom Resource Provider always gets chosen first and, if it is not able to create a resource, the creation request does not fall back to less specific providers or the root provider even though those provider might well be able to create the resource. 
> The common pattern across many of the ResourceResolver operations is to poll all viable Resource Providers.  For example, getResource will iterate over all viable Resource Providers in order of path specificity, stopping only if one of them is able to return a resource.  The attached patch implements a similar mechanism for the create and delete commands.  
> Create will iterate over all viable ModifyingResourceProviders in order of specificity, stopping if one of them actually produces a Resource.  Delete will iterate over all viable ModifyingResourceProviders giving each a crack at deleting the resource.  



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