Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Konrad Windszus]

I clarified 
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
 
.
 I will later publish those changes.

> On 20 Sep 2016, at 11:41, Konrad Windszus  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?
>  
>   
> >
> Thanks,
> Konrad
> 
>> On 20 Sep 2016, at 11:08, Carsten Ziegeler > > 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 
 :
 
 Hi Konrad,
 
 On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus  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  
>> >

Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Konrad Windszus]

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?
 

Thanks,
Konrad

> On 20 Sep 2016, at 11:08, Carsten Ziegeler  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 :
>>> 
>>> Hi Konrad,
>>> 
>>> On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus  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 

Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Carsten Ziegeler]

> 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 :
>>
>> Hi Konrad,
>>
>> On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus  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

Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Konrad Windszus]

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?
Is there some servlet filter implemented which overwrites the 
HttpServletRequest.getPathInfo()?

Thanks,
Konrad

> Am 20.09.2016 um 10:13 schrieb Bertrand Delacretaz :
> 
> Hi Konrad,
> 
> On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus  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

Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Bertrand Delacretaz]

Hi Konrad,

On Mon, Sep 19, 2016 at 11:37 AM, Konrad Windszus  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

Re: Clarification on https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html

[Konrad Windszus]

This also does not seem to be 100% correct.
Just think about the following example:

There is a resource named "/a/b.c". Then the decomposition is as follows:

For "/a/b.c.html" the resource path would be "/a/b.c" and the extension would 
be "html", selectors would be null and suffix null.
For "/a/b.c/d" the resource path would be "/a/b" and the extension would be 
"c", selectors would be null and suffix "/d".
For "/a/b/c.html/test" the resource path would be "/a/b/c" the extension would 
be "html", selectors would be null and the suffix would be "/test"

So basically we have to distinguish between existing and non existing resource 
paths:

For existing paths, the resource path is the longest match (incl. mapping 
rules) where the next character is either a dot or it is the full request url.
Otherwise (for non-existing path) the separation is done at the first dot in 
the request url which splits resource path (non-existing) from the rest.

Am I correct with that assumption?
Thanks,
Konrad


> On 19 Sep 2016, at 11:22, Konrad Windszus  wrote:
> 
> I would like to extend the documentation in 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
>  a bit.
> 
> Basically for the Resource Path section it says:
> 
> Resource Path - The longest substring of the request URL such that the 
> resource path is either the complete request URL or the next character in the 
> request URL after the resource path is a dot (.).
> 
> I would like to modify that to:
> 
> Resource Path - The longest substring of the request URL pointing to an 
> existing resource (taking into account any resource mapping rules) such that 
> this part is either the full request URL or the next character in the request 
> URL after the resource path is a dot (.). 
> Without knowing the repository structure it is impossible to say which part 
> of the request URL is the resource path, because the resource path does not 
> necessarily end with the first dot (.) in the request url, as resource names 
> itself and therefore the resource path as well may contain dots (.). 
> Therefore it is impossible to tell just by looking at the request URL string 
> how it is gonna be decomposed by Sling.
> 
> This is IMHO an important aspect and should be explicitly mentioned on the 
> page 
> https://sling.apache.org/documentation/the-sling-engine/url-decomposition.html
> 
> Is everyone fine with that change?
> Konrad
> 
> P.S. This change is triggered by the PR 
> https://github.com/apache/sling/pull/172 which incorrectly assumes that the 
> first dot separates the resource path from the rest.