I clarified 
http://sling.staging.apache.org/documentation/the-sling-engine/url-decomposition.html
 
<http://sling.staging.apache.org/documentation/the-sling-engine/url-decomposition.html>
 in r1761914 and r1761917. Please quickly cross-check 
http://sling.staging.apache.org/documentation/the-sling-engine/url-decomposition.html
 
<http://sling.staging.apache.org/documentation/the-sling-engine/url-decomposition.html>.
 I will later publish those changes.

> On 20 Sep 2016, at 11:41, Konrad Windszus <konra...@gmx.de> wrote:
> 
> 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?><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 <cziege...@apache.org 
>> <mailto:cziege...@apache.org>> 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 
>>>> <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 <mailto:cziege...@apache.org> 
>> <mailto:cziege...@apache.org <mailto:cziege...@apache.org>>

Reply via email to