> 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 <bdelacre...@apache.org>: >> >> Hi Konrad, >> >> On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus <konra...@gmx.de> 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 cziege...@apache.org
