I can confirm that case 1) does work. > If a ResourceProvider has a root of > /foo/bar, then it > shouldn't be expected to return resources for anything not > starting with /foo/bar. agree, but in case of "listChildren" on any path/node/resource we could consult all resource providers (which "correspond to"/include this path) and concat all children. Hence we might even end up with same-named-siblings coming from different resource providers
> -----Original Message----- > From: Justin Edelson [mailto:justinedel...@gmail.com] > Sent: Monday, August 23, 2010 6:20 PM > To: dev@sling.apache.org > Subject: Re: [DISCUSS] Correct listing of resource children (follow up > to SLING-1672) > > > Case 1 should be working in trunk now. What's the > <Sling-Bundle-Resources> header look like? > > In terms of case 2, if this was to be implemented, I don't think it > should be up to the ResourceProvider implementation to create the > SyntheticResource. If a ResourceProvider has a root of > /foo/bar, then it > shouldn't be expected to return resources for anything not > starting with > /foo/bar. > > Even though this is easy to workaround, if we're serious about > supporting WebDAV over the resource tree, supporting this is probably > necessary. > > Justin > > On 8/23/10 4:17 AM, Mike Müller wrote: > > Hi > > > > When getting a resource the case seems to be clear: > > The first resource provider which returns a resource > > *wins*. And the resource providers are called in order > > starting with the provider which is registered for the > > longest part of the requested path. > > With ResourceResolver#listChildren it's a bit trickier. > > Assume the following: > > > > structure in the JCR: > > > > /foo > > /foo/bar > > /foo/bar/test > > > > and in another resource provider: > > > > /foo/bar > > /foo/bar/myresource > > > > case 1) > > ResourceResolver#listChildren( "/foo/bar" ) should now > > list the following > > > > test > > myresource > > > > case 2) > > Assume another provider: > > /some/path/resource > > /some/path/resource2 > > > > What should ResourceResolver#listChildren( "/" ) list? > > From my understanding it should list: > > > > foo > > some > > > > where may be a SyntheticResource. > > > > case 1) and case 2) are not returning the expected result, at least > > not if you use a bundle resource provider. I haven't looked into the > > details so I can't say if it's a problem of the bundle resource > > provider or a more general problem with the resource resolver > > implementation. > > > > Maybe security could be a problem. But a resource provider at least > > can access the user id via ResourceResolver#getUserID, and > list children > > only if access is allowed. I don't know if this behavour of a > > resource provider is intended. > > > > WDYT? > > > > best regards > > mike > >
