Hi Olaf,
Sorry, I don't know how to explain this any better than what I said
earlier in the week. There is no inconsistency.
For a request like /root/child.html, Sling will try *first* for the
full resource path /root/child.html. Since your resource provider is
rooted at /root, it is asked for the reosurce at /root/child.html. If
no resource can be found at this path, Sling *next* tries to get the
resource /root/child. Since your resource provider is rooted at /root,
it is asked for this resource as well.
Sling will behave differently depending on which call returns a non-null value.
getResource("/root/child.html") - Sling will try to serve the resource
directly to the client, usually by adapting it to an InputStream
getResource("/root/child") - Sling will then try to execute the "html"
or default script for this resource type.
You wrote this in your JIRA issue which I think identifies the problem:
> In essence, a ResourceProvider can not utilize any selectors or extensions to
> parametrize the resolution of its root resource.
A ResourceProvider should *never* do this, whether on the root
resource or any other resource. Selectors and extensions are not meant
to parameterize resource resolution.
Justin
On Fri, Jan 17, 2014 at 3:38 AM, Olaf Otto <[email protected]> wrote:
> Hello Justin
>
> I believe we have a misunderstanding: You are absolutely right - but I have
> no intention to alter the described behavior. What I mean is that the
> behavior of the resource resolution using a resolved provider is
> inconsistent as it differs between the root path and (potential) child paths
> of a ResourceProvider. Let me elaborate:
>
> Let /root be the root of the resource provider. When I resolve
> /root/child.html, the resource provider is looked up in the fashion you
> described below, and is subsequently asked to resolve the entire request
> path, i.e. /root/child.html. When /root.html is called, and there is no
> specific provider for /root.html, the provider is looked up in the fashion
> you described, and is subsequently called - and this is the important
> difference - with the *lookup path* for the provider - i.e. /root.
>
> It is clear that /root.html is not a child of /root *by default*. However,
> when no specific provider for /root.html exists, the provider of /root
> becomes responsible for the resolution of the path, i.e. /root.html is then
> treated as a child of /root. Consequently, the provider should be asked to
> provide the *entire* path, i.e. including and extensions / selectors etc,
> just like for any other child resource it is responsible for.
>
> The patch I attached to SLING-3319 does not alter the behavior you described
> below (that would indeed be very nasty) but simply provides the full path to
> be resolved to the provider responsible.
>
> This behavior would be consistent with the behavior for JcrResourceProvider:
> As this provider has the root path "/", it will always be asked to resolve
> the entire resource path (including extensions and selectors) as
> "/.selectors.extensions" is usually not resolved, i.e. it is always asked to
> resolve a child.
>
> Kind regards,
> Olaf
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Justin Edelson
> Sent: Dienstag, 14. Januar 2014 19:22
> To: [email protected]
> Subject: Re: ResourceProvider not invoked when provider root path is called
> with HTML extension
>
> Hi,
> IIUC, this is *entirely* expected.
>
> Your ResourceProvider's root is /content/child1/child2. When the request
> comes in for /content/child1/child2.html, Sling will first try to resolve
> that full path. Your provider will *not* be consulted at this point because
> /content/child1/child2.html is not a child of
> /content/child1/child2 (it is a sibling). When the full path cannot be
> resolved, Sling then does its path decomposition thing and tries to resolve
> /content/child1/child2, which succeeds via your ResourceProvider.
>
> When a request comes in for /content/child1/child2/child3.html, the same
> thing happens. First, Sling tries to resolve the full path and does consult
> your resource provider (because /content/child1/child2/child3.html is a
> descendant of /content/child1/child2). At this point, if your provider
> returns null (and no other provider returns a non-null result), the Sling
> engine will THEN ask your provider for /content/child1/child2/child3.
>
> HTH,
> Justin
>
> On Tue, Jan 14, 2014 at 12:53 PM, Felix Meschberger <[email protected]>
> wrote:
>> Hi
>>
>> Well, this gets really tricky, because as has been said, this is not
> expected.
>>
>> The only advice I can give here is to do some (remote) debugging with a
> debugger and step through the process from the SlingMainServlet (actually
> probably RequestData.initResource).
>>
>> Regards
>> Felix
>>
>> Am 14.01.2014 um 00:56 schrieb Olaf Otto <[email protected]>:
>>
>>> Hello
>>>
>>> Apparently, the behavior that the root path with .html extension was
>>> not resolved at all was due to some persistent invalid internal state
>>> of the resource resolver. After modifying an arbitrary resolver
>>> setting, the root resource is now resolved (I re-installed Sling and
>>> the entire application to make sure this remains the case).
>>>
>>> However, there still is an important difference:
>>>
>>> When requesting "/content/child1/child2/child3.html", the path passed
>>> to the resource provider is "/content/child1/child2/child3.html",
>>> i.e. includes the extension. When requesting
>>> /content/child1/child2.html, the resolver only sees the path
>>> "/content/child1/child2". Since I am doing a subsequent resource
>>> resolution, this results in a missing resolutionPathInfo=".html" of the
> resolved resource.
>>>
>>> Thus, the remaining question is: Why are extensions not passed to the
>>> provider in case the root path is requested?
>>>
>>> Kind regards,
>>> Olaf
>>>
>>> -----Original Message-----
>>> From: Olaf Otto [mailto:[email protected]]
>>> Sent: Dienstag, 14. Januar 2014 07:29
>>> To: [email protected]
>>> Subject: RE: ResourceProvider not invoked when provider root path is
>>> called with HTML extension
>>>
>>> Hello,
>>>
>>> Thank you for the quick replies! The /child2 path is exclusively
>>> provided by the custom resource provider. Would anyone know a hint
>>> why this just happens in case of a .html extension? There must be
>>> some other actor influencing this behavior.
>>>
>>> Kind regards,
>>> Olaf
>>>
>>> -----Original Message-----
>>> From: Felix Meschberger [mailto:[email protected]]
>>> Sent: Montag, 13. Januar 2014 23:38
>>> To: [email protected]
>>> Subject: Re: ResourceProvider not invoked when provider root path is
>>> called with HTML extension
>>>
>>> Hi
>>>
>>> As Alex said, this is not expected, but .
>>>
>>> Do you happen to have a node /content/child1/child2.html in the
> repository ?
>>> If so, this would overwrite the ResourceProvider because it has a
>>> full path match as opposed to just ./child2.
>>>
>>> Regards
>>> Felix
>>>
>>> Am 13.01.2014 um 14:09 schrieb Olaf Otto <[email protected]>:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I have created a resource provider adding content as children into a
>>>> tree of existing JCR content, like this:
>>>>
>>>>
>>>>
>>>> /content/child1 ß JCR content
>>>>
>>>> /content/child1/child2 ß Provided by ResourceProvider
>>>>
>>>>
>>>>
>>>> This works as expected: child2 is returned as a child of child1, and
>>>> invoking /content/child1/child2 yields the provided resource.
>>>> However, when calling /content/child1/child2.html, the resource
>>>> provider is never asked for a resource. Instead, the default get
>>>> servlet returns a synthetic resource, causing a redirect to
>>>> /content/child1/child2.html/, resulting in a 404. Using a different
>>>> extension works - when I call /content/child1/child2.json, the
>>>> provider is called. Children of the root path however work with a
>>>> .html extension: A request to /content/child1/child2/child3.html is
>>>> mapped
>>> to the resource provider.
>>>>
>>>>
>>>>
>>>> I have played with the resource provider's properties, trying both
>>>> /content/child1/child2 and /content/child1/child2/ as root and
>>>> setting owns root to true. This had no effect - the provider is only
>>>> called if /content/child1/child2.html is added as a root path. This,
>>>> however, is not an acceptable solution as child1 features both
>>>> child2 and child2.html as children afterwards.
>>>>
>>>>
>>>>
>>>> In summary, this looks like a bug to me - am I right or am I missing
>>>> a piece of the puzzle?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Olaf
>>>>
>>>
>>>
>>>
>>
>
