Hi, A patch with this solution is attached to https://issues.apache.org/jira/browse/SLING-3657. I'll commit in another day or two unless there are concerns.
Regards, Justin On Wed, Aug 27, 2014 at 3:50 PM, Justin Edelson <jus...@justinedelson.com> wrote: > Hi, > We still seem to have a disagreement about the benefits/wisdom of > exposing a service which merges resources. I have an alternative which > I think solves for both the desire to have flexible resource selection > algorithms and not expose resources outside the context of the > ResourceResolver. > > We create a SPI interface called MergedResourceSelector. This has a > single method: > > Iterator<Resource> selectResourcesToMerge(ResourceResolver, String) > > OSGi services implementing this interface must also have a merge.root > service property. > > In the resource merger bundle, we have a whiteboard which listens for > these services and, for each, it registers a ResourceProviderFactory > which references the Selector service and uses the merge.root service > property for the provider.roots property of the > ResourceProviderFactory. The ResourceProvider is an implementation > detail of the resourcemerger bundle. > > This is essentially what I'm trying to implement anyway (where the > AbstractMergingResourceProvider has all of the merging logic) for > SLING-3657; the only difference is that rather than using a class > hierarchy, we use OSGi services. > > > WDYT? > > Justin
