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 <o...@x100.de>: > 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:o...@x100.de] > Sent: Dienstag, 14. Januar 2014 07:29 > To: users@sling.apache.org > 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:fmesc...@adobe.com] > Sent: Montag, 13. Januar 2014 23:38 > To: users@sling.apache.org > 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 <o...@x100.de>: > >> 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 >> > > >
