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 <cziege...@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 > cziege...@apache.org
signature.asc
Description: Message signed with OpenPGP
