Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3
    • Component/s: Servlets
    • Labels:
      None

      Description

      According to the findings in the dev list thread "Simplifying script paths and names?" at [1] I would now like to propose the implementation of this change in script/servlet path resolution:

      Note: This issue talks about scripts. But as servlets are mirrored into the virtual Resource Tree accessible through the ResourceResolver, servlets are treated exactly the same as scripts (or vice-versa actually). So the discussion applies to servlets as well as to scripts.

      (1) Script Location

      Scripts to handle the processing or a resource are looked up in a single location:

      {scriptPathPrefix}/{resourceTypePath}

      Where {scriptPathPrefix}

      is an absolute path prefix (as per ResourceResolver.getSearchPath()) to get absolute paths and

      {resourceTypePath} is the resource type converted to a path. If the {resourceTypePath}

      is actually an absolute path, the

      {scriptPathPrefix}

      is not used.

      Example: Given the search path [ "/apps", "/libs" ] and a resource type of sling:sample, the following locations will be searched for scripts:

      • /aps/sling/script
      • /libs/sling/script

      (2) Within the location(s) found through above mechanism a script is searched whose script name matches the pattern

      {resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}

      where the fields have the following meaning:

      {resourceTypeLabel}

      - the last segment of the

      {resourceTypePath}

      (see above)
      This part is required. Only scripts whose name starts with this name are considerd

      {selectorString}

      - the selector string as per RequestPathInfo.getSelectorString
      This part is optional. The more selectors of the selector string match, the
      better.

      {requestMethod}

      The request method name. This is optional for GET or HEAD requests
      and is required for non-GET/non-HEAD requests

      {requestExtension}

      The extension of the request. This is optional.

      {scriptExtension}

      The extension indicating the script language. Not used for selecting
      the script but for selecting the ScriptEngine. This is of course not existing
      for servlets.

      If multiple scripts would apply for a given request, the script with the best match is selected. Generally speaking a match is better if it is more specific. More in detail, a match with more selector matches is better than a match with less selector matches, regardless of any request extension or method name match.

      For example, consider a request to resource /foo/bar.print.a4.html of type sling:sample. Assuming we have the following list of scripts in the correct location:

      (1) sample.esp
      (2) sample.GET.esp
      (3) sample.GET.html.esp
      (4) sample.html.esp
      (5) sample.print.esp
      (6) sample.print.a4.esp
      (7) sample.print.html.esp
      (8) sample.print.GET.html.esp
      (9) sample.print.a4.html.esp
      (10) sample.print.a4.GET.html.esp

      It would probably be (10) - (9) - (6) - (8) - (7) - (5) - (3) - (4) - (2) - (1). Note that (6) is a better match than (8) because it matches more selectors even though (8) has a method name and extension match where (6) does not.

      If there is a catch, e.g. between print.esp and print.jsp, the first script in the listing would be selected (of course, there should not be a catch...)

      [1] http://markmail.org/message/odduiwskv7ogdtz2

      1. SLING387.patch
        138 kB
        Felix Meschberger
      2. SLING387.patch
        142 kB
        Bertrand Delacretaz

        Issue Links

          Activity

          Gavin made changes -
          Workflow re-open possible,doc-test-required [ 12788404 ] no-reopen-closed,doc-test-required [ 12792949 ]
          Gavin made changes -
          Workflow no-reopen-closed,doc-test-required [ 12766369 ] re-open possible,doc-test-required [ 12788404 ]
          Gavin made changes -
          Workflow Copy of no-reopen-closed,doc-test-required [ 12764895 ] no-reopen-closed,doc-test-required [ 12766369 ]
          Gavin made changes -
          Workflow no-reopen-closed,doc-test-required [ 12475160 ] Copy of no-reopen-closed,doc-test-required [ 12764895 ]
          Felix Meschberger made changes -
          Component/s Scripting [ 12311942 ]
          Component/s Servlets Resolver [ 12312086 ]
          Component/s Servlets [ 12313028 ]
          Felix Meschberger made changes -
          Workflow jira [ 12429333 ] no-reopen-closed,doc-test-required [ 12475160 ]
          Felix Meschberger made changes -
          Status In Progress [ 3 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Hide
          Felix Meschberger added a comment -

          In Rev. 654438 finalized implementation of this issue:

          • Refactored resolution of error handler servlets/scripts to use new mechanism
          • Removed unused methods and classes
          • Renamed helper classes to reflect their functionality

          Closing this issue for now. Errors in the new implementation should be reported in new issues.

          Show
          Felix Meschberger added a comment - In Rev. 654438 finalized implementation of this issue: Refactored resolution of error handler servlets/scripts to use new mechanism Removed unused methods and classes Renamed helper classes to reflect their functionality Closing this issue for now. Errors in the new implementation should be reported in new issues.
          Hide
          Felix Meschberger added a comment - - edited

          Request Selectors are ignored for non-GET/HEAD requests. Hence the POST-related test is expected to fail. This is related to issue (III) in [1] stating that not all request methods are equal.

          Hence, I suggest to for the moment comment out these tests with a comment stating this situation and not implementing that support. Reason for this is, that a resource URL should address the resource (and at most give some hint for a specific representation, such as html or txt) but not include an operation such as delete.

          [1] http://markmail.org/message/tksvk4xfwapdpkwo

          Show
          Felix Meschberger added a comment - - edited Request Selectors are ignored for non-GET/HEAD requests. Hence the POST-related test is expected to fail. This is related to issue (III) in [1] stating that not all request methods are equal. Hence, I suggest to for the moment comment out these tests with a comment stating this situation and not implementing that support. Reason for this is, that a resource URL should address the resource (and at most give some hint for a specific representation, such as html or txt) but not include an operation such as delete. [1] http://markmail.org/message/tksvk4xfwapdpkwo
          Hide
          Bertrand Delacretaz added a comment -

          Added ScriptSelectionTest in revision 653378, with the testHtmlPostSelectors commented out as it fails.

          Show
          Bertrand Delacretaz added a comment - Added ScriptSelectionTest in revision 653378, with the testHtmlPostSelectors commented out as it fails.
          Hide
          Felix Meschberger added a comment -

          Implemented first step of refactoring in Rev. 653326.

          Remains: Check error handler script/servlet resolution and clean up unused code.

          Show
          Felix Meschberger added a comment - Implemented first step of refactoring in Rev. 653326. Remains: Check error handler script/servlet resolution and clean up unused code.
          Felix Meschberger made changes -
          Link This issue relates to SLING-419 [ SLING-419 ]
          Hide
          Felix Meschberger added a comment -

          The correct script path would be .../delete/POST.esp

          Show
          Felix Meschberger added a comment - The correct script path would be .../delete/POST.esp
          Hide
          Bertrand Delacretaz added a comment -

          I haven't found out how to hook a script to POST with a "delete" selector, tried POST.delete.html.esp and various other options but that didn't work.

          Looking at the code, I think that might not work at all, and I didn't find tests related to this.

          Show
          Bertrand Delacretaz added a comment - I haven't found out how to hook a script to POST with a "delete" selector, tried POST.delete.html.esp and various other options but that didn't work. Looking at the code, I think that might not work at all, and I didn't find tests related to this.
          Bertrand Delacretaz made changes -
          Attachment SLING387.patch [ 12381195 ]
          Hide
          Bertrand Delacretaz added a comment -

          Updated patch that also removes some classes under sling/servlets-get

          Show
          Bertrand Delacretaz added a comment - Updated patch that also removes some classes under sling/servlets-get
          Felix Meschberger made changes -
          Attachment SLING387.patch [ 12381192 ]
          Hide
          Felix Meschberger added a comment -

          This patch should implemented the latest decision from [1]

          As soon as SVN gets back up, I will try to check this in.

          [1] http://markmail.org/message/tksvk4xfwapdpkwo

          Show
          Felix Meschberger added a comment - This patch should implemented the latest decision from [1] As soon as SVN gets back up, I will try to check this in. [1] http://markmail.org/message/tksvk4xfwapdpkwo
          Hide
          David Nuescheler added a comment -

          i think it is important that this change was originally suggested to
          make the simple cases as simple and intuitive as possible for
          the user of sling and not to come up with something that is really
          easy and consistent to map for the sling implementation.

          let me try to explain with an example:
          as a user of sling i would like to have my app in
          /apps/myapp and lets say i have a node of resourceType
          "myapp/homepage" at "/content/myapp".

          i would like to to be able to structure my applications as follows:

          (1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp)
          (2) /apps/myapp/homepage/edit.esp (or edit.html.esp)
          (3) /apps/myapp/homepage/header/highlight.jpg.esp
          (4) /apps/myapp/homepage/header/selected.jpg.esp
          (5) /apps/myapp/homepage/header/small.jpg.esp

          where

          /content/myapp.html -> (1)
          /content/myapp.edit.html -> (2)
          /content/myapp.header.highlight.jpg -> (3)
          /content/myapp.header.selected.jpg -> (4)
          /content/myapp.header.small.jpg -> (5)

          i think it is important that we avoid unnecessary repetition at any point
          and we would allow for enough flexibility in the /apps directory allow
          the user to come up with something short, distinct and meaningful.

          Show
          David Nuescheler added a comment - i think it is important that this change was originally suggested to make the simple cases as simple and intuitive as possible for the user of sling and not to come up with something that is really easy and consistent to map for the sling implementation. let me try to explain with an example: as a user of sling i would like to have my app in /apps/myapp and lets say i have a node of resourceType "myapp/homepage" at "/content/myapp". i would like to to be able to structure my applications as follows: (1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp) (2) /apps/myapp/homepage/edit.esp (or edit.html.esp) (3) /apps/myapp/homepage/header/highlight.jpg.esp (4) /apps/myapp/homepage/header/selected.jpg.esp (5) /apps/myapp/homepage/header/small.jpg.esp where /content/myapp.html -> (1) /content/myapp.edit.html -> (2) /content/myapp.header.highlight.jpg -> (3) /content/myapp.header.selected.jpg -> (4) /content/myapp.header.small.jpg -> (5) i think it is important that we avoid unnecessary repetition at any point and we would allow for enough flexibility in the /apps directory allow the user to come up with something short, distinct and meaningful.
          Felix Meschberger made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Felix Meschberger made changes -
          Assignee Felix Meschberger [ fmeschbe ]
          Hide
          Felix Meschberger added a comment -

          the initial "*" in the lines is just a numbering symbol. It has no code significance. And yes, your fixes are correct.

          Show
          Felix Meschberger added a comment - the initial "*" in the lines is just a numbering symbol. It has no code significance. And yes, your fixes are correct.
          Hide
          Bertrand Delacretaz added a comment -

          > Given the search path [ "/apps", "/libs" ] and a resource type of sling:sample, the following locations will be
          > searched for scripts:

          > * /aps/sling/script
          > * /libs/sling/script

          I think this should be

          /apps/sling/sample
          /lib/sling/sample

          And I'm not sure what the initial */ means in your example, I thought the search paths were absolute.

          Show
          Bertrand Delacretaz added a comment - > Given the search path [ "/apps", "/libs" ] and a resource type of sling:sample, the following locations will be > searched for scripts: > * /aps/sling/script > * /libs/sling/script I think this should be /apps/sling/sample /lib/sling/sample And I'm not sure what the initial */ means in your example, I thought the search paths were absolute.
          Felix Meschberger made changes -
          Field Original Value New Value
          Description According to the findings in the dev list thread "Simplifying script paths and names?" at [1] I would now like to propose the implementation of this change in script/servlet path resolution:

          Note: This issue talks about scripts. But as servlets are mirrored into the virtual Resource Tree accessible through the ResourceResolver, servlets are treated exactly the same as scripts (or vice-versa actually). So the discussion applies to servlets as well as to scripts.

          (1) Script Location

          Scripts to handle the processing or a resource are looked up in a single location:

               {scriptPathPrefix}/{resourceTypePath}

          Where {scriptPathPrefix} is an absolute path prefix (as per ResourceResolver.getSearchPath()) to get absolute paths and {resourceTypePath} is the resource type converted to a path. If the {resourceTypePath} is actually an absolute path, the {scriptPathPrefix} is not used.

          Example: Given the search path [ "/apps", "/libs" ] and a resource type of sling:sample, the following locations will be searched for scripts:

               * /aps/sling/script
               * /libs/sling/script


          (2) Within the location(s) found through above mechanism a script is searched whose script name matches the pattern

               {resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}

          where the fields have the following meaning:

               {resourceTypeLabel} - the last segment of the {resourceTypePath} (see above)
                              This part is required. Only scripts whose name starts with this name are considerd
               {selectorString} - the selector string as per RequestPathInfo.getSelectorString
                              This part is optional. The more selectors of the selector string match, the
                              better.
               {requestMethod}
                              The request method name. This is optional for GET or HEAD requests
                              and is required for non-GET/non-HEAD requests
               {requestExtension}
                              The extension of the request. This is optional.
               {scriptExtension}
                               The extension indicating the script language. Not used for selecting
                               the script but for selecting the ScriptEngine. This is of course not existing
                               for servlets.


          If multiple scripts would apply for a given request, the script with the best match is selected. Generally speaking a match is better if it is more specific. More in detail, a match with more selector matches is better than a match with less selector matches, regardless of any request extension or method name match.

          For example, consider a request to resource /foo/bar.print.a4.html of type sling:sample. Assuming we have the following list of scripts in the correct location:

             (1) print.esp
             (2) print.a4.esp
             (3) print.html.esp
             (4) print.GET.html.esp
             (5) print.a4.html.esp
             (6) print.a4.GET.html.esp

          It would probably be (6) - (5) - (2) - (4) - (3) - (1). Note that (2) is a better match than (4) because it matches more selectors even though (4) has a method name and extension match where (2) does not.

          If there is a catch, e.g. between print.esp and print.jsp, the first script in the listing would be selected (of course, there should not be
          a catch...)



          [1] http://markmail.org/message/odduiwskv7ogdtz2
          According to the findings in the dev list thread "Simplifying script paths and names?" at [1] I would now like to propose the implementation of this change in script/servlet path resolution:

          Note: This issue talks about scripts. But as servlets are mirrored into the virtual Resource Tree accessible through the ResourceResolver, servlets are treated exactly the same as scripts (or vice-versa actually). So the discussion applies to servlets as well as to scripts.

          (1) Script Location

          Scripts to handle the processing or a resource are looked up in a single location:

               {scriptPathPrefix}/{resourceTypePath}

          Where {scriptPathPrefix} is an absolute path prefix (as per ResourceResolver.getSearchPath()) to get absolute paths and {resourceTypePath} is the resource type converted to a path. If the {resourceTypePath} is actually an absolute path, the {scriptPathPrefix} is not used.

          Example: Given the search path [ "/apps", "/libs" ] and a resource type of sling:sample, the following locations will be searched for scripts:

               * /aps/sling/script
               * /libs/sling/script


          (2) Within the location(s) found through above mechanism a script is searched whose script name matches the pattern

               {resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}

          where the fields have the following meaning:

               {resourceTypeLabel} - the last segment of the {resourceTypePath} (see above)
                              This part is required. Only scripts whose name starts with this name are considerd
               {selectorString} - the selector string as per RequestPathInfo.getSelectorString
                              This part is optional. The more selectors of the selector string match, the
                              better.
               {requestMethod}
                              The request method name. This is optional for GET or HEAD requests
                              and is required for non-GET/non-HEAD requests
               {requestExtension}
                              The extension of the request. This is optional.
               {scriptExtension}
                               The extension indicating the script language. Not used for selecting
                               the script but for selecting the ScriptEngine. This is of course not existing
                               for servlets.


          If multiple scripts would apply for a given request, the script with the best match is selected. Generally speaking a match is better if it is more specific. More in detail, a match with more selector matches is better than a match with less selector matches, regardless of any request extension or method name match.

          For example, consider a request to resource /foo/bar.print.a4.html of type sling:sample. Assuming we have the following list of scripts in the correct location:

             (1) sample.esp
             (2) sample.GET.esp
             (3) sample.GET.html.esp
             (4) sample.html.esp
             (5) sample.print.esp
             (6) sample.print.a4.esp
             (7) sample.print.html.esp
             (8) sample.print.GET.html.esp
             (9) sample.print.a4.html.esp
             (10) sample.print.a4.GET.html.esp

          It would probably be (10) - (9) - (6) - (8) - (7) - (5) - (3) - (4) - (2) - (1). Note that (6) is a better match than (8) because it matches more selectors even though (8) has a method name and extension match where (6) does not.

          If there is a catch, e.g. between print.esp and print.jsp, the first script in the listing would be selected (of course, there should not be a catch...)



          [1] http://markmail.org/message/odduiwskv7ogdtz2
          Hide
          Felix Meschberger added a comment -

          To be clear: This new mechanism replaces the script resolution mechanism of today. As such this change is not backwards compatible and existing applications will have to be adapted.

          Show
          Felix Meschberger added a comment - To be clear: This new mechanism replaces the script resolution mechanism of today. As such this change is not backwards compatible and existing applications will have to be adapted.
          Felix Meschberger created issue -

            People

            • Assignee:
              Felix Meschberger
              Reporter:
              Felix Meschberger
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development