Hi
That's exactly what I was thinking of: Not the Resource Provider
implementations should be responsible for the synthetic resources
but the ResourceResolver implementation.
So a big +1 from my side.
best regards
mike
> 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
> >
>
>
