You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/08/25 15:15:44 UTC
[jira] Created: (SLING-627) Virtual URLs break script resolution
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.
[jira] Commented: (SLING-627) Virtual URLs break script resolution
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625354#action_12625354 ]
Tobias Bocanegra commented on SLING-627:
----------------------------------------
i think virtual url should just allow mapping of 'directories' and not full urls.
so /sample could map to /content/some/where/samples
mapping requests from http://host/sample to another path should only be done with (http) redirects. otherwise the confusion is endless
as you problem shows.
> 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.
[jira] Closed: (SLING-627) Virtual URLs break script resolution
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-627.
-----------------------------------
Resolution: Fixed
Fix Version/s: Engine 2.0.4
Implemented the fixes:
* Extended the ResourceMetadata API with a new sling.resolutionPathInfo property
* Extended JcrResourceResolver to provide the new property in the resource metadata
* Modified SlingRequestPathInfo class to use the new property
After committing the respective fixes to the api, jcr/resource and engine modules, I consider this issue fixed.
> 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, Engine 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.
[jira] Commented: (SLING-627) Virtual URLs break script resolution
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.