[
https://issues.apache.org/jira/browse/SLING-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625647#action_12625647
]
Felix Meschberger commented on SLING-627:
-----------------------------------------
YMMV and as we already have this functionality built into the resource
resolver, we should really implement the stuff correctly. In addition we might
add additional path adaptions to the resolve methods, which also cause the the
actual path used to retrieve the resource is completely different from the
original request path. This would also not be supported by the current
implementation.
In addition the old SlingRequestPathInfo implementation was based on the
assumption upon the actual path used by the resource resolver to access the
resource. This was bad anyway, because this used implementation knowledge of
the resource resolver, which IMHO is not allowed anyway.
> Virtual URLs break script resolution
> ------------------------------------
>
> Key: SLING-627
> URL: https://issues.apache.org/jira/browse/SLING-627
> Project: Sling
> Issue Type: Bug
> Components: API, JCR Resource
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: API 2.0.4, JCR Resource 2.0.4
>
>
> Consider a virtual URL configuration in the JcrResourceResolver mapping the
> URL "/sample" to "/content/some/where/in/the/path.print.a4.html".
> When using the URL "/content/some/where/in/the/path.print.a4.html", the
> resource resolver correctly resolves the "/content/some/where/in/the/path"
> resource and sets the selector string (print.a4) and extension (html)
> correctly. When accessing the URL "/sample", the resource is correclty
> resolved again to "/content/some/where/in/the/path". But the selector string
> and extension are empty.
> The reason for this is the cooperation between the JcrResourceResovler and
> the SlingRequestPathInfo and the RequestData class. The JcrResourceResolver
> sets up the Resoure correctly with the ResourceMetadata containing a property
> sling.resolutionPath set to "/content/some/where/in/the/path". The
> RequestData.initServlet method uses the Resource (with the correct
> sling.resolutionPath field) and the servlet request's path info
> (ServletRequest.getPathInfo()) to find the selectors and extension etc.
> The problem with virtual URLs is, that the path info is the originally
> requested URL -- /sample in this case -- while the resource resolution path
> is something completely different. Hence the request path info details cannot
> be extracted.
> To be able to fix this situation, we should add a new field in the
> ResourceMetadata, which takes the part of the URL path used to resolve the
> resoure, which is not path of the resource path, such that:
> resolutionFullPath = sling.resolutionPath + sling.resolutionPathInfo
> The SlingRequestPathInfo class will then only inspoect the
> sling.resolutionPathInfo field to split that into selectors, extension and
> suffix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
