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
