[
https://issues.apache.org/jira/browse/SLING-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-5773.
------------------------------------
Resolution: Won't Fix
Agree, let's close as Won't Fix.
> NonExistingResource.getParent() must consider the resource resolver mapping
> ---------------------------------------------------------------------------
>
> Key: SLING-5773
> URL: https://issues.apache.org/jira/browse/SLING-5773
> Project: Sling
> Issue Type: Bug
> Components: API
> Affects Versions: API 2.11.0
> Reporter: Konrad Windszus
> Priority: Major
>
> 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/[email protected]/msg56405.html.
> and the related ticket SLING-5757.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
