Hi,
On 24.08.2010 09:51, Julian Sedding wrote:
> Hi Felix
>
> The proposal looks good, +1. I've some additional thoughts:
>
> If resources are provided by several ResourceProviders, does it matter
> which one provides the resource? E.g. the sling:resourceType might
> vary. So I believe that the order in which ResourceProviders are asked
> to provide a certain resource needs to be guaranteed.
It is: providers are asked from the bottom of the tree to the top, thus
giving the longest prefix-path matching provider first. If on a certein
tree level more than one provider is registered, these providers are
asked in order of their ranking (service.ranking and service.id service
registration properties).
>
> If this assumption holds true, couldn't the synthetic resources be
> provided by a SyntheticResourceProvider, which would be internal to
> the ResourceResolver. This SyntheticResourceProvider should be
> registered as the last one in the list of ResourceProviders. The
> synthetic resources could then be pre-created upon registration of
> servlets or ResourceProviders. Reusing the ResourceProvider concept to
> handle this special case should make it less special and thus would
> IMHO allow keep the code simple.
>
> WDYT?
I am not sure, whether this really helps or just makes the code more
complicated.
We in fact have an internal tree structure of resource providers. The
actual resource providers are registered at varous levels in thise tree.
We walk this tree to find the resources to list. So in fact this tree is
the virtual SyntheticResource provider.
Regards
Felix
>
> Regards
> Julian
>
>
>
> On Tue, Aug 24, 2010 at 9:11 AM, Felix Meschberger <fmesc...@gmail.com> wrote:
>> 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
>>>
>>
>>
>
