> I can confirm that case 1) does work. ...at least for FsResourceProvider resources, but not for BundleResourceProvider resources :-( Mixing jcr resources with bundle resources still doesn't work as expected.
Having: > <Sling-Bundle-Resources> > > /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer > </Sling-Bundle-Resources> and then creating the res/sling/explorer jcr structure (through WebDAV for example) only enlists the jcr tree but not the "mixed in" bundle resources > -----Original Message----- > From: Clemens Wyss [mailto:clemens...@mysign.ch] > Sent: Monday, August 23, 2010 7:56 PM > To: 'dev@sling.apache.org'; 'jus...@justinedelson.com' > Subject: RE: [DISCUSS] Correct listing of resource children (follow up > to SLING-1672) > > > 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 > > > > >
