[
https://issues.apache.org/jira/browse/SLING-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914543#comment-13914543
]
Carsten Ziegeler commented on SLING-3420:
-----------------------------------------
The use case we have, is merging of product and customer specific
configurations - the default config delivered with the product is at /libs/bla
and once the customer does changes, they of course should be add /apps/bla
I think my initial proposal is too much magic for what is actually needed,
especially as it is trying to mess with the hiding properties.
So I refine my proposal:
- by default all changes are done on the first search page (default
installation this is /apps), like with the servlet resolver we provide a
configuration to override this
- create: a node at the first search path is created
- update: either the node at the first search path is updated, or if it doesn't
exist, it's created
- delete: if a node at the first search path exists, its removed
- changes are only allowed if there are at least two search paths
> 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)
