[jira] [Comment Edited] (SLING-3420) Implement ModifyingResourceProvider

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

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

Carsten Ziegeler edited comment on SLING-3420 at 2/28/14 7:04 AM:
------------------------------------------------------------------

We can automate the common case, special casing can be done by hand anyway. No one forces you to use this. In our use case we don't need to know where exactly the updated configurations are stored, we just one to update, add, delete them without ever touching the initially shipped ones.
But I just realize that my latest proposal could also simply be done by adding a utility method to the resource merging service which does the path magic and switches it from /mnt/overlay/bla to /apps/bla
Would that work for you?


was (Author: cziegeler):
We can automate the common case, special casing can be done by hand anyway. No one forces you to use this

> Implement ModifyingResourceProvider
> -----------------------------------
>
>                 Key: SLING-3420
>                 URL: https://issues.apache.org/jira/browse/SLING-3420
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>    Affects Versions: Resource Merger 1.0.0
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>             Fix For: Resource Merger 1.0.2
>
>
> The resource merger merges resources from the search paths. This is very useful for reading/getting such resources.
> However, as soon as you want to modify, create or delete such resources the code doing so needs more knowledge about how the resource merger works. And the code needs to switch from the mount path to a search path etc.
> Therefore, the resource merging provider could directly implement the modifying resource provider:
> - if the resource resolver is configured with less than two search paths, modifying is denied
> - the last search path (e.g. by default /libs/) is considered to be unchangeable, so all operations are done on a higher search path
> 1. Create
> This creates a node at the second last search path (e.g. /apps)
> 2. Delete
> If there is a node at /libs, a node hiding this one is created at /apps. Otherwise the node at /apps is removed
> 3. Update
> Creates/updates a node at /apps
> All these methods need to check whether resource hiding is used and adjust the properties accordingly



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)