Thanks, got it. Indeed the algorithm seems to differ whether it resolves to an existing path or a non-existing path. Are there any more tests for the resolve method except for the basic ones in https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/resourceresolver/src/test/java/org/apache/sling/resourceresolver/impl/ResourceResolverImplTest.java#L318? <https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/resourceresolver/src/test/java/org/apache/sling/resourceresolver/impl/ResourceResolverImplTest.java#L318?> Thanks, Konrad
> On 20 Sep 2016, at 11:08, Carsten Ziegeler <[email protected]> wrote: > >> Hi Bertrand, I agree that referencing test cases is for sure good and >> validating those assumptions with those as well (if that is not yet the >> case). Currently though I have troubles to find the according code. >> The selector, extension and suffix handling is in >> https://github.com/apache/sling/blob/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java >> and nicely tested in >> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/engine/src/test/java/org/apache/sling/engine/impl/request/SlingRequestPathInfoTest.java. >> >> But the part which actually extracts the resource from the request url is >> hard to find. So the place where the resource path is separated from the >> rest. >> I only found >> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/engine/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L232 >> which just relies on HttpServletRequest.getPathInfo() to call >> ResourceResolver.resolve with that path. But that will always use the full >> path (everything up to the query part of the URL) as resource path, which is >> obviously not true. >> >> Can someone give me a pointer where in the code the longest resource path >> followed by „.“ algorithm is implemented to find the resource path? > > Everything is done in ResourceResolverImpl.resolve and the methods > called from there. I think the real work is done in one of the > resolveInternal methods > > Carsten > >> Is there some servlet filter implemented which overwrites the >> HttpServletRequest.getPathInfo()? >> >> Thanks, >> Konrad >> >>> Am 20.09.2016 um 10:13 schrieb Bertrand Delacretaz <[email protected]>: >>> >>> Hi Konrad, >>> >>> On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus <[email protected]> wrote: >>>> ...So basically we have to distinguish between existing and non existing >>>> resource paths... >>> >>> Even if someone knew these details off the top of their head (which I >>> don't) IMO the only sane way to document these things in a foolproof >>> way is with automated tests. Keep the docs at the overview / basic >>> principles level, and put the Whole Truth in readable tests. >>> >>> I think the script resolution page [1], which points to the >>> ScriptSelectionTest [2] is a good example of that, that we might want >>> to replicate for the URL decomposition components. >>> >>> -Bertrand >>> >>> [1] >>> https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html >>> [2] >>> http://svn.apache.org/repos/asf/sling/trunk/bundles/servlets/resolver/src/test/java/org/apache/sling/servlets/resolver/internal/helper/ScriptSelectionTest.java >> >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] <mailto:[email protected]>
