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