> 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 > > > 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
I definitively think we should support this behavour. And I totaly agree that this should not be up to the ResourceProvider implementation to create the SyntheticResource objects for the parts of the path above. So in case 2) the ResourceResolver implementation should create SyntheticResource objects for "/some" and "/some/path" if the root path (provider.roots) is set to /some/path. Beneath /some/path the ResourceProvider implementation must make sure that traversing the resource tree down to a deeply nested provided resource is possible. best regards mike > > > > 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 > > > > >
