[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027657#comment-14027657
]
Justin Edelson commented on SLING-3657:
---------------------------------------
[~gknob] there needs to be a separate mount point per merge semantics as each
set of merge semantics has to be implemented by a separate resource provider.
AFAICT, we've identified three separate merge cases:
1) Merge relative paths based on search path (exists)
2) Merge absolute paths based on resource type hierarchy (this issue)
3) Merge relative paths based on an arbitrary set of path roots (discussed on
mailing list, needs component factory)
Each of these (and multiple in the case of #3) would be rooted at a separate
mount point.
IMHO SLING-3423 is ultimately orthogonal to this issue - if SLING-3423 existed,
the code in this patch would look different, but there would still need to be a
resource provider at /mnt/override which merged resources based on resource
type inheritance.
> Create a ResourceMerger-style ResourceProvider which merges based on resource
> super types
> -----------------------------------------------------------------------------------------
>
> Key: SLING-3657
> URL: https://issues.apache.org/jira/browse/SLING-3657
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Justin Edelson
> Attachments: SLING-3657.patch
>
>
> The current MergingResourceProvider does a good job of a single use case -
> merging resources relative to the search paths. A second use case for merging
> is to merge resources based on their sling:resourceSuperType inheritance, i.e.
> /content/siteA@sling:resourceSuperType=/content/siteB
> /content/siteB@sling:resourceSuperType=/content/siteC
> It should be possible to generate a merged resource which combines
> /content/siteA, /content/siteB, and /content/siteC (in reverse order so that
> siteA overrides siteB, etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
