Hi,
Here is what I would see to be intended.
For case (1) the ResourceResolver must mix the results of calling
listChildren("/for/bar") on all resource providers providing resource at
or below said path. In this case the BundleResourceProvider and the
JcrResourceProvider.
For case (2) the ResourceResolver must create these intermediary
SyntheticResource instances to be able to traverse down to the "mount
point" of provided resources.
Case (2) seems to work, though: when you deploy my whiteboard WebDAV
bundle, you will for example see the subtree below /libs, e.g.
/libs/sling/redirect. This subtree is entirely synthetic and created on
the fly.
In the case of the ServletResourceProvider part of the work is done in
the ServletResourceProvider (see ServletResourceIterator.seek() method).
The ResourceResolver calls the ResourceProvider.listChildren method on
each resource provider registered with a path which is a substring of
the parent path or which includes the parent path.
Maybe this kind of code should be moved to the ResourceResolver creating
these synthetic intermediaries for locations below which a
ResourceProvider is attached.
Now, the BundleResourceProvider is not operating like this. For example
there is the Sling POST Servlet bundle registering the /system/sling.js
script. This script is never returned by the BundleResourceProvider's
listChildren implementation.
So what we probably should do is the following:
* The ResourceResolver.listChildren method calls the
ResourceProvider.listChildren method of all resource providers
registered at or _above_ the location whose children are to be
listted
* Next the for each ResourceProvider registered _below_ the location
whose childre are to be listed a SyntheticResource is created
(unless an actual resource exists) for the next segment towards
the registered ResourceProvider.
Example: Consider three resource providers registered at "/", "/libs",
and "/libs/sling/servlet/default". Now we want to list the children
of "/libs/sling".
- First the listChildren method of the "/" and "/libs" providers are
called with the parent path "/libs/sling"
- Next for the "/libs/sling/servlet/default" provider a synthetic
resource is created for "/libs/sling/servlet" unless this resource
has already been returned by one of the other providers.
WDYT ?
Regards
Felix
Regards
Felix
On 23.08.2010 10:17, 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
>
