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)
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
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)
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 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 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
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 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
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
[DISCUSS] Correct listing of resource children (follow up to SLING-1672)
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 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
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
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 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 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. ...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 -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
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: 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
