Hi Justin Thank you for the clarification! So, in summary, when /something is resolved for /something.html, the question is not whether something.html is a child of /something, but whether .html I an extension of the sibling resource /something. That's where I got it wrong.
Kind regards, Olaf -----Original Message----- From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of Justin Edelson Sent: Freitag, 17. Januar 2014 14:57 To: users@sling.apache.org Subject: Re: ResourceProvider not invoked when provider root path is called with HTML extension Hi Olaf, Sorry, I don't know how to explain this any better than what I said earlier in the week. There is no inconsistency. For a request like /root/child.html, Sling will try *first* for the full resource path /root/child.html. Since your resource provider is rooted at /root, it is asked for the reosurce at /root/child.html. If no resource can be found at this path, Sling *next* tries to get the resource /root/child. Since your resource provider is rooted at /root, it is asked for this resource as well. Sling will behave differently depending on which call returns a non-null value. getResource("/root/child.html") - Sling will try to serve the resource directly to the client, usually by adapting it to an InputStream getResource("/root/child") - Sling will then try to execute the "html" or default script for this resource type. You wrote this in your JIRA issue which I think identifies the problem: > In essence, a ResourceProvider can not utilize any selectors or extensions to parametrize the resolution of its root resource. A ResourceProvider should *never* do this, whether on the root resource or any other resource. Selectors and extensions are not meant to parameterize resource resolution. Justin On Fri, Jan 17, 2014 at 3:38 AM, Olaf Otto <o...@x100.de> wrote: > Hello Justin > > I believe we have a misunderstanding: You are absolutely right - but I > have no intention to alter the described behavior. What I mean is that > the behavior of the resource resolution using a resolved provider is > inconsistent as it differs between the root path and (potential) child > paths of a ResourceProvider. Let me elaborate: > > Let /root be the root of the resource provider. When I resolve > /root/child.html, the resource provider is looked up in the fashion > you described below, and is subsequently asked to resolve the entire > request path, i.e. /root/child.html. When /root.html is called, and > there is no specific provider for /root.html, the provider is looked > up in the fashion you described, and is subsequently called - and this > is the important difference - with the *lookup path* for the provider - i.e. /root. > > It is clear that /root.html is not a child of /root *by default*. > However, when no specific provider for /root.html exists, the provider > of /root becomes responsible for the resolution of the path, i.e. > /root.html is then treated as a child of /root. Consequently, the > provider should be asked to provide the *entire* path, i.e. including > and extensions / selectors etc, just like for any other child resource it is responsible for. > > The patch I attached to SLING-3319 does not alter the behavior you > described below (that would indeed be very nasty) but simply provides > the full path to be resolved to the provider responsible. > > This behavior would be consistent with the behavior for JcrResourceProvider: > As this provider has the root path "/", it will always be asked to > resolve the entire resource path (including extensions and selectors) > as "/.selectors.extensions" is usually not resolved, i.e. it is always > asked to resolve a child. > > Kind regards, > Olaf > > -----Original Message----- > From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On > Behalf Of Justin Edelson > Sent: Dienstag, 14. Januar 2014 19:22 > To: users@sling.apache.org > Subject: Re: ResourceProvider not invoked when provider root path is > called with HTML extension > > 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 > <fmesc...@adobe.com> > 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 <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 >>>> >>> >>> >>> >> >
