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