Hi Justin, yepp I was going to comment on the name as well :) We definitely should avoid "Selector". With this mechanism, we always use the same merging algorithm and "only" make the source for merging pluggable. Sounds like a good compromise, at least we're not leaking any fake resources.
And this would still work with optionally supporting CRUD (Picker could set a serive prop for that). Carsten 2014-08-28 13:28 GMT+02:00 Justin Edelson <[email protected]>: > 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] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
