Yepp, exactly - so a resource provider and that includes the resource access security implementation should never return a NonExistingResource - otherwise the getResource() contract of the ResourceResolver will be broken.
So, I'll go ahead and change this Thanks Carsten 2013/12/17 Alexander Klimetschek <[email protected]> > On 16.12.2013, at 04:38, Dominik Süß <[email protected]> wrote: > > > There is currently a gap between the behavior of .resolve() and > .getResource() > > where getResource would return null and .resolve() should return a > > NonExistingResource. I'm pretty sure there is a reason for that, but I > > couldn't find it. > > Oh, yes, there is a good reason for that: > > - resolve() is used for request processing, where it is necessary to > handle the non-existing case with the special sling:nonexisting resource > type and the original path info > - getResource() is the more "raw" access, similar to JCR Session.getNode() > (*) > > Applications would always use getResource() and handle the null check. > resolve() is mostly only for the sling engine, or if you have some more > complex internal forwarding etc. that requires to replicate Sling's > resolution behavior. > > (*) yes, getNode() throws an exception, but that's similar to returning > null compared to returning a special NonExistingResource object > > Cheers, > Alex > > -- Carsten Ziegeler [email protected]
