Hi Justin, I'm not sure if I understand this proposal completely. So let's assume the current merge provider would be implemented with this, it would register this selector service with the root property set to /mnt/merge. This gets picked up and a resource provider with the same root is registered. When now a resource is requested from the provider, like /mnt/merge/foo/baa, the selector service is called first with /foo/baa as the second parameter and it would return the existing resources relative to the search paths, so e.g. /libs/foo/baa and /apps/foo/baa. The merge is done and the merged resource is returned by the provider. Is this roughly what you are envisioning? This could work, however I fear we need two methods - like we have in the provider interface: one for getting a resource at a specific path and one to list the children.
Carsten 2014-08-27 21:50 GMT+02:00 Justin Edelson <[email protected]>: > 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 > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
