He he, that's the use case I was always pushing for... Mixing one resource provider (/mnt/overlay) with the generic resource merger concept in one service prevents from doing so. And IMO (one step further than your use case) it might not only be a resource provider that consumes the merger service, so there should be a resource merger service that merges resources for you and then you write a provider or something else for your specific case.
Cheers, Alex On 30.05.2014, at 13:55, Justin Edelson <[email protected]> wrote: > Hi, > I have a feeling that I'm going to regret not having followed > SLING-3423 closely enough :) > > I have a use case where I need to combine two arbitrary resource trees > (e.g. /content/siteA and /content/siteB). This seems like a natural > match for the sling resource merger, but it seems like right now that > only supports a single ResourceProvider and always gets the merge > sources from the resource resolver search path. > > I can't quite tell from SLING-3423 if this was thought through and > decided was a non-goal or if it just wasn't an immediate term goal. > Can someone clarify? > > In reading through that JIRA issue and > http://sling.markmail.org/thread/3wt33wniwgflmk27, I can't see a > reason why there shouldn't be multiple MergedResourceProviders (IIOW, > MergedResourceProviderFactory should be a factory component), each > with a different mount root and sources. Am I missing something? > > Thanks, > Justin
