Hi Carsten, Yes that is essentially the idea. You may be correct that a second selector method is necessary; I haven't figured out all of the details yet, but I wanted to get some conensus on the concept before diving in.
Also, it occurs to me that "Picker" might be better than "Selector" as we use that term to mean something else in Sling. Justin On Thu, Aug 28, 2014 at 4:45 AM, Carsten Ziegeler <[email protected]> wrote: > 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]
