> 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?
Everything is done in ResourceResolverImpl.resolve and the methods
called from there. I think the real work is done in one of the
> 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 , which points to the
>> ScriptSelectionTest  is a good example of that, that we might want
>> to replicate for the URL decomposition components.
Adobe Research Switzerland