Hi everyone I found the issue - luckily, it is a simple one:
https://issues.apache.org/jira/browse/SLING-3319 In essence, the split() function of ResourceProviderEntry requires a fix. Kind regards, Olaf -----Original Message----- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Dienstag, 14. Januar 2014 18:54 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension 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 >> > > >
