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 >
