[
https://issues.apache.org/jira/browse/SLING-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916470#comment-13916470
]
Alexander Klimetschek commented on SLING-3420:
----------------------------------------------
I just note that the ResourceMergerService is not implemented as intended. It
should operate on a freely defined list of merge paths:
Resource merge(ResourceResolver resolver, String mergeRootPath, String
relativePath, String... mergePaths)
See my mail on the list: http://sling.markmail.org/thread/3wt33wniwgflmk27
And the original patch:
https://github.com/gknob/sling-resourcemerger/commit/a3e1b78c87e54cd5c32a58627a4de0420229e1f9
Thus it is clear that writing automatically is never possible. Even the slight
improvement of the utility method as part of the service is wrong. With a list
of N merge paths, the service can never automatically know where to write.
The logic of "if it's not in /libs then write to /apps" is very specific to
whatever use case you have at hand. What if there are more than 2 entries?
Which one wins? And sometimes you want to overwrite something at /libs.
Regarding the use case of merging configurations: I doubt that there should be
an automatic way to write those. The end user triggering the configuration
change should be aware where he does the change. It cannot be hidden somewhere
in a layer deep inside the server, this looks wrong to me. Where is this
configuration merge used?
> 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)
