Uploaded image for project: 'Sling'
  1. Sling
  2. SLING-5773

NonExistingResource.getParent() must consider the resource resolver mapping

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Won't Fix
    • API 2.11.0
    • None
    • API
    • None

    Description

      Consider the case you have a resource resolver mapping from "/content/" to "/". In the underlying repository you have a resource in "/content/existingParent".

      Now it might happen that a NonExistingResource is resolved for path "/existingParent/nonExistingResource". Since this is pointing towards a non-existing resource the mapping is not active (i.e. the path will not contain "/content"). So you end up with a NonExistingResource with path "/existingParent/nonExistingResource".
      Now you call getParent() on this resource.

      You would expect to end up with an existing resource in "/content/existingParent" (because that path does exist in the repository). Unfortunately due to the logic in AbstractResource.getParent() this just calls ResourceResolver.getParent() which will not use ResourceResolver.resolve(...) but rather ResourceResolver.getResource(...) internally. So the mapping is not considered here. Therefore no resource is found at "/existingParent", although it does exist at "/content/existingParent".

      This is unexpected and wrong in my opinion. So the NonExistingResource should not rely on AbstractResource.getParent() at all, but rather use its own implementation relying on ResourceResolver.resolve(...).

      See also http://www.mail-archive.com/dev@sling.apache.org/msg56405.html.
      and the related ticket SLING-5757.

      Attachments

        Issue Links

          Activity

            kwin It seems we didn't really come to a conclusion, on the other hand this issue is now open for 5 years; should we rather resolve as won't fix?

            cziegeler Carsten Ziegeler added a comment - kwin It seems we didn't really come to a conclusion, on the other hand this issue is now open for 5 years; should we rather resolve as won't fix?

            Agree, let's close as Won't Fix.

            kwin Konrad Windszus added a comment - Agree, let's close as Won't Fix.

            People

              Unassigned Unassigned
              kwin Konrad Windszus
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: