[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037662#comment-16037662
]
Alexander Klimetschek edited comment on SLING-848 at 6/5/17 9:51 PM:
---------------------------------------------------------------------
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
was (Author: alexander.klimetschek):
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
> Support getting versioned resources by using uri path parameters
> ----------------------------------------------------------------
>
> Key: SLING-848
> URL: https://issues.apache.org/jira/browse/SLING-848
> Project: Sling
> Issue Type: New Feature
> Components: API, JCR, ResourceResolver
> Affects Versions: JCR Resource 2.0.2
> Reporter: Carsten Ziegeler
> Assignee: Tomek Rękawek
> Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0
>
> Attachments: SLING-848-metadata.patch
>
>
> Getting versioned content should be support thorough uri path parameters,
> like /something/hello;v=1.1
> For jcr based resources the value of the version should either point to a
> version name or label.
> In order to not change our existing apis, we introduce a new utility method
> which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utility
> method and then decide to act on these
> parameters.
> If a requested version does not exists, a 404 is returned.
> If the requested node does not directly point to a versionable node, the
> algorithm checks the parent hierarchy until a versionable node is found, and
> tries to get the version of this node and then goes down the path again. If
> the versionable node does not have the requested version or the child, a 404
> is returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
