[
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3730.
-------------------------------------
Resolution: Fixed
> ResourceResolver does not always set the metadata "sling.resolutionPath"
> properly
> ---------------------------------------------------------------------------------
>
> Key: SLING-3730
> URL: https://issues.apache.org/jira/browse/SLING-3730
> Project: Sling
> Issue Type: Bug
> Affects Versions: JCR Resource 2.3.6, Resource Resolver 1.1.0
> Reporter: Konrad Windszus
> Assignee: Carsten Ziegeler
> Priority: Critical
> Fix For: JCR Resource 2.3.8, Resource Resolver 1.1.2
>
> Attachments: rewriter-issue-1.0.zip
>
>
> This metadata is evaluated by calling:
> SlingHttpServletRequest.getRequestPathInfo().getResourcePath() (you can see
> how this field is initially set in
> org.apache.sling.engine.impl.request.SlingRequestPathInfo, line 59). This is
> e.g. the case in
> org.apache.sling.rewriter.impl.ProcessorConfigurationImpl.match(ProcessorConfigurationImpl.java:411).
> If it returns null like it does for MergedResources (due to that metadata
> not being set) that leads easily to NPEs like in the example with the
> SlingRewriter.
> According to the Javadocs of RequestPathInfo
> (https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/request/RequestPathInfo.java)
> I would assume that getResourcePath() never returns null. For all the other
> methods it is explicitly stated if they are expected to return null in some
> cases. All the other Resources like SyntheticResource or JcrItemResource
> already set that metadata in their constructor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
