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 
 and nicely tested in 

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 
 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?
Is there some servlet filter implemented which overwrites the 


> 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

Reply via email to