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 >>> >> >> >> >
