[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16038448#comment-16038448
]
Carsten Ziegeler edited comment on SLING-848 at 6/6/17 9:31 AM:
----------------------------------------------------------------
I don't think a configuration would work as this means its either on or off, so
as soon as you have both use cases, you're in a dead end. But I would like to
understand the problem space a little bit more.
If your resource path is using a semicolon and you're using this in a url, you
have to encode it - this has always been the case as the semicolon denotes uri
parameters and these are stripped off by servlet engines like jetty. With the
implementation of this issue, we just use the uri parameter to get the version,
so we're using additional information.
When implementing this additional support we decided to support the same syntax
in getResource() to allow to get a version of a resource. Otherwise there would
be no way to specify this.
Now, if we revert something we did for this issue, we break other peoples code
using exactly that feature.
On the other hand, getResource() should not have magic, as it should use the
path as is.
Maybe there is any easy way out, the paths we care for are of this sort:
/content/test;v='1.0'
so there is a name and a value.
Based on that , we could change getResource into:
- no semicolon : use path as is
- semicolon but no equals sign in uri parameter, use path as is
- semicolon and equals sign, use as (version) parameter
While this is maybe not the easiest to understand, it will implement both use
cases without a configuation.
And as the quick check is checking for a semicolon, there shouldn't be a
performance penality
And potentially we should implement the same logic in resolve()
was (Author: cziegeler):
I don't think a configuration would work as this means its either on or off, so
as soon as you have both use cases, you're in a dead end. But I would like to
understand the problem space a little bit more.
If your resource path is using a semicolon and you're using this in a url, you
have to encode it - this has always been the case as the semicolon denotes uri
parameters and these are stripped off by servlet engines like jetty. With the
implementation of this issue, we just use the uri parameter to get the version,
so we're using additional information.
When implementing this additional support we decided to support the same syntax
in getResource() to allow to get a version of a resource. Otherwise there would
be no way to specify this.
Now, if we revert something we did for this issue, we break other peoples code
using exactly that feature.
On the other hand, getResource() should not have magic, as it should use the
path as is.
Maybe there is any easy way out, the paths we care for are of this sort:
/content/test;v='1.0'
so there is a name and a value.
Based on that , we could change getResource into:
- no semicolon : use path as is
- semicolon but no equals sign in uri parameter, use path as is
- semicolon and equals sign, use as (version) parameter
While this is maybe not the easiest to understand, it will implement both use
cases without a configuation.
And as the quick check is checking for a semicolon, there shouldn't be a
performance penality
> 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)
