You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Roy Teeuwen <ro...@teeuwen.be> on 2017/09/14 15:47:25 UTC
New Resource Provider SPI - limitations
Hey all,
We are currently upgrading our environment, and of course the new resource provider SPI is now available. But it seems that our current resource provider would not be able to be used in this new SPI, seeing as in the old one you could dynamically look if the resource provider could return a resource for the request, and if not just return null, letting the next resource provider have a look.
Seeing as the old resource provider is deprecated, what would be the recommended approach to have the same kind of logic:
- Register on root level
- Check if the request has something that we are looking for (in our situation we are looking for a specific structure in the requested url)
- If yes, return a resource, if no let the default resource provider do their job
I could of course wait until the old resource provider api has really been removed, but I would rather work proactively :)
Greets,
Roy
Re: New Resource Provider SPI - limitations
Posted by Roy Teeuwen <ro...@teeuwen.be>.
Hey Carsten,
I have tested it further, and it seems that both the old and the new resource provider api has the same bug. Correct me if i'm wrong that it's a bug, but the following occurs:
- The resource provider gets deployed on a specific root (lets say /content/my-site/a-page), either the old api or the new spi
- Next time sling gets restarted, the JcrResourceProvider comes into this function: org.apache.sling.resourceresolver.impl.providers.ResourceProviderTracker#updateProviderContext
- Seeing as we now have a path /content/my-site/a-page, this will be added to the excludedPaths of JcrResourceProvider
- We can now no longer query to anything below /content/my-site/a-page. For example if there is a sling:alias on /content/my-site/a-page/jcr:content, it will not be loaded anymore on startup, nor will you be able to query any resources below it.
This used to work in the old api, I think because there was nothing like this excludedPaths functionality in the old api? You maybe got any suggestions on how to make it work in the current situation, either with the old or the new api, I have tried both now
Greets,
Roy
> On 18 Sep 2017, at 16:10, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Roy Teeuwen wrote
>> Hey Carsten,
>>
>> Thanks for the info! It seems by the way that the current implementation actually even breaks Slin when still using the old ResourceProvider api.
>>
>> When you have for example a api.ResourceProvider mounted on path /content, it will be added to the excludedPaths of the ProviderContext => These paths are used in the BasicQueryLanguageProvider when doing a query in the resource resolver and returning a JcrNodeResourceIterator, making it that no results are returned anymore from /content.
>>
>> I don't know if I should register this as a bug? What is the policy of deprecated classes? Shouldn't they still work as designed until they actually get removed?
>>
> Hi,
>
> yes, deprecated classes should work as designed, so this might be a bug.
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: New Resource Provider SPI - limitations
Posted by Carsten Ziegeler <cz...@apache.org>.
Roy Teeuwen wrote
> Hey Carsten,
>
> Thanks for the info! It seems by the way that the current implementation actually even breaks Slin when still using the old ResourceProvider api.
>
> When you have for example a api.ResourceProvider mounted on path /content, it will be added to the excludedPaths of the ProviderContext => These paths are used in the BasicQueryLanguageProvider when doing a query in the resource resolver and returning a JcrNodeResourceIterator, making it that no results are returned anymore from /content.
>
> I don't know if I should register this as a bug? What is the policy of deprecated classes? Shouldn't they still work as designed until they actually get removed?
>
Hi,
yes, deprecated classes should work as designed, so this might be a bug.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: New Resource Provider SPI - limitations
Posted by Roy Teeuwen <ro...@teeuwen.be>.
Hey Carsten,
Thanks for the info! It seems by the way that the current implementation actually even breaks Slin when still using the old ResourceProvider api.
When you have for example a api.ResourceProvider mounted on path /content, it will be added to the excludedPaths of the ProviderContext => These paths are used in the BasicQueryLanguageProvider when doing a query in the resource resolver and returning a JcrNodeResourceIterator, making it that no results are returned anymore from /content.
I don't know if I should register this as a bug? What is the policy of deprecated classes? Shouldn't they still work as designed until they actually get removed?
Greets,
Roy
> On 15 Sep 2017, at 17:10, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> to simplify the processing of providers we removed the explicit fallback
> to a "higher" provider. However, your resource provider gets a context
> which it can use to get a resource from a higher provider. So instead of
> returning null you explicitely call the parent and return that result
> from the parent.
>
> Regards
> Carsten
>
> Roy Teeuwen wrote
>> Hey all,
>>
>> We are currently upgrading our environment, and of course the new resource provider SPI is now available. But it seems that our current resource provider would not be able to be used in this new SPI, seeing as in the old one you could dynamically look if the resource provider could return a resource for the request, and if not just return null, letting the next resource provider have a look.
>>
>> Seeing as the old resource provider is deprecated, what would be the recommended approach to have the same kind of logic:
>>
>> - Register on root level
>> - Check if the request has something that we are looking for (in our situation we are looking for a specific structure in the requested url)
>> - If yes, return a resource, if no let the default resource provider do their job
>>
>> I could of course wait until the old resource provider api has really been removed, but I would rather work proactively :)
>>
>> Greets,
>> Roy
>>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: New Resource Provider SPI - limitations
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
to simplify the processing of providers we removed the explicit fallback
to a "higher" provider. However, your resource provider gets a context
which it can use to get a resource from a higher provider. So instead of
returning null you explicitely call the parent and return that result
from the parent.
Regards
Carsten
Roy Teeuwen wrote
> Hey all,
>
> We are currently upgrading our environment, and of course the new resource provider SPI is now available. But it seems that our current resource provider would not be able to be used in this new SPI, seeing as in the old one you could dynamically look if the resource provider could return a resource for the request, and if not just return null, letting the next resource provider have a look.
>
> Seeing as the old resource provider is deprecated, what would be the recommended approach to have the same kind of logic:
>
> - Register on root level
> - Check if the request has something that we are looking for (in our situation we are looking for a specific structure in the requested url)
> - If yes, return a resource, if no let the default resource provider do their job
>
> I could of course wait until the old resource provider api has really been removed, but I would rather work proactively :)
>
> Greets,
> Roy
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org