On 8/23/10 2:48 PM, Clemens Wyss wrote: >> 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 This is SLING-1675. What's working in trunk is if Sling-Bundle-Resources was /res/sling.
Already mentioned, but to be clear, overwrite and uninstall don't apply to bundle resources. Justin > >> -----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 >>> >>> >>
