Hi, As I explained the other day, this is not a bug. The desired change is a (rather severe) violation of the ResourceProvider contract.
Regards, Justin On Thu, Jan 16, 2014 at 6:41 PM, Olaf Otto <[email protected]> wrote: > Hi everyone > > I invested more time into the analysis of the issue and did some updates > (https://issues.apache.org/jira/browse/SLING-3319), including a patch. If > someone could try / review / discuss it, that would be great. > > Regards, > Olaf > > -----Original Message----- > From: Olaf Otto [mailto:[email protected]] > Sent: Donnerstag, 16. Januar 2014 08:49 > To: [email protected] > Subject: RE: ResourceProvider not invoked when provider root path is called > with HTML extension > > 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:[email protected]] > Sent: Dienstag, 14. Januar 2014 18:54 > To: [email protected] > 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 <[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 >>> >> >> >> > > >
