New Resource Provider SPI - limitations

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New Resource Provider SPI - limitations

Roy Teeuwen
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

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Resource Provider SPI - limitations

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: New Resource Provider SPI - limitations

Roy Teeuwen
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 <[hidden email]> 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
> [hidden email]


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Resource Provider SPI - limitations

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: New Resource Provider SPI - limitations

Roy Teeuwen
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 <[hidden email]> 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
> [hidden email]


signature.asc (817 bytes) Download Attachment