[
https://issues.apache.org/jira/browse/SLING-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-3730:
-----------------------------------
Description:
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.
was: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.
> MergedResource does not 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: Resource Merger 1.1.2
> Reporter: Konrad Windszus
> Priority: Critical
>
> 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)