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
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?
> On 19 Sep 2016, at 11:22, Konrad Windszus <konra...@gmx.de> wrote:
> I would like to extend the documentation in
> 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
> Is everyone fine with that change?
> 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.