You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Justin Edelson (JIRA)" <ji...@apache.org> on 2014/06/11 03:17:01 UTC

[jira] [Updated] (SLING-3657) Create a ResourceMerger-style ResourceProvider which merges based on resource super types

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

Justin Edelson updated SLING-3657:
----------------------------------

    Attachment: SLING-3657.patch

Here's a patch for this. I would still like to add some tests. Functionally, this seems OK to me.

The default mount point is /mnt/override. To this, you append the *full* path, i.e. /mnt/override/content/siteA.

This is different than the existing merging resource provider where the path after /mnt/overlay is relative to the search paths.

> 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)