Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
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 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 prov
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi, This is already the case because all resource providers on a certain level are ordered according to their ServiceReference.compareTo. Thus the service.ranking and service.id are considered for the ordering. Regards Felix On 24.08.2010 17:52, Carsten Ziegeler wrote: > Mike Müller wrote >> Hi >> >> That seems to be a good way to implement it. IIRC the resource providers >> are called in order starting with the provider which is registered >> for the longest part of the requested path. If that is correct the >> SyntheticResourceProvider (which I rather would name something like >> PathNodeProvider) should be registered for "/", where also the >> JcrResourceProvider is registered. The question is now, how the >> resource provider which are registered for the same path could be >> further ordered (the service id doesn't seem to be a good idea). >> Any idea? >> > We could use service.ranking property - the standard way of defining an > order in such cases. > > Carsten
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Mike Müller wrote > Hi > > That seems to be a good way to implement it. IIRC the resource providers > are called in order starting with the provider which is registered > for the longest part of the requested path. If that is correct the > SyntheticResourceProvider (which I rather would name something like > PathNodeProvider) should be registered for "/", where also the > JcrResourceProvider is registered. The question is now, how the > resource provider which are registered for the same path could be > further ordered (the service id doesn't seem to be a good idea). > Any idea? > We could use service.ranking property - the standard way of defining an order in such cases. Carsten -- Carsten Ziegeler cziege...@apache.org
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi
That seems to be a good way to implement it. IIRC the resource providers
are called in order starting with the provider which is registered
for the longest part of the requested path. If that is correct the
SyntheticResourceProvider (which I rather would name something like
PathNodeProvider) should be registered for "/", where also the
JcrResourceProvider is registered. The question is now, how the
resource provider which are registered for the same path could be
further ordered (the service id doesn't seem to be a good idea).
Any idea?
best regards
mike
> 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.
>
> 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?
>
> Regards
> Julian
>
>
>
> On Tue, Aug 24, 2010 at 9:11 AM, Felix Meschberger
> 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/pa
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
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.
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?
Regards
Julian
On Tue, Aug 24, 2010 at 9:11 AM, Felix Meschberger 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
>>
>
>
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
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
> >
>
>
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
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
>
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
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: >> >> >> /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer >> > 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 >>> 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 >>> >>> >>
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
> 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: > > > /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer > 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 > > 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 > > > > >
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 > > > Case 1 should be working in trunk now. What's the > > 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 I definitively think we should support this behavour. And I totaly agree that this should not be up to the ResourceProvider implementation to create the SyntheticResource objects for the parts of the path above. So in case 2) the ResourceResolver implementation should create SyntheticResource objects for "/some" and "/some/path" if the root path (provider.roots) is set to /some/path. Beneath /some/path the ResourceProvider implementation must make sure that traversing the resource tree down to a deeply nested provided resource is possible. best regards mike > > > > 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 > > > > >
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 > 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 > >
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Case 1 should be working in trunk now. What's the 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
