You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Tobias Bocanegra (Created) (JIRA)" <ji...@apache.org> on 2011/10/21 12:24:32 UTC
[jira] [Created] (SLING-2253) Resource resolver fails to work with
expanded JCR paths
Resource resolver fails to work with expanded JCR paths
-------------------------------------------------------
Key: SLING-2253
URL: https://issues.apache.org/jira/browse/SLING-2253
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR Resource 2.0.10
Environment: org.apache.sling.jcr.resource-2.0.11-R1142950.jar
Reporter: Tobias Bocanegra
retrieving a resource addressed with an expanded JCR path does not work (anymore).
eg:
resource.getResourceResolver().getResource("/content/test/{http://www.jcp.org/jcr/1.0}content") == null
where as:
resource.getResourceResolver().getResource("/content/test/jcr:content") == <resource>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2253) Resource resolver fails to work
with expanded JCR paths
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133881#comment-13133881 ]
Felix Meschberger commented on SLING-2253:
------------------------------------------
Using an expanded patch probably never really worked: The getResource() method starts off with normalizing the patch, which just replaces double slashes with single slashes. Thus converts "/content/test/{http://www.jcp.org/jcr/1.0}content" to "/content/test/{http:/www.jcp.org/jcr/1.0}content" already making the path illegal.
Also, if multi workspace resolution would be enabled the URL inside the expanded path --- http://.... --- would trigger the path to be assumed to be multi workspace indicating http to be the workspace name.
So, all-in-all, it must be said, that at the moment such expanded paths are not supported. In addition such paths, IIRC, have not been supported in JCR 1.0 and have only been introduced in JCR 2.0.
Theoretically we could add support for expanded paths, in that we check for the "/{" substring in the getResource method and specially handle such paths. But this would break at least one level of abstraction (one might consider the namespace mangling support in the resolve method has the same weakness !). In addition I am not sure about the general use of such support....
> Resource resolver fails to work with expanded JCR paths
> -------------------------------------------------------
>
> Key: SLING-2253
> URL: https://issues.apache.org/jira/browse/SLING-2253
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Resource 2.0.10
> Environment: org.apache.sling.jcr.resource-2.0.11-R1142950.jar
> Reporter: Tobias Bocanegra
>
> retrieving a resource addressed with an expanded JCR path does not work (anymore).
> eg:
> resource.getResourceResolver().getResource("/content/test/{http://www.jcp.org/jcr/1.0}content") == null
> where as:
> resource.getResourceResolver().getResource("/content/test/jcr:content") == <resource>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira