[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172111#comment-17172111 ] Konrad Windszus commented on SLING-848: --- Documentation PR at https://github.com/apache/sling-site/pull/49/files. [~tomek.rekawek] WDYT? > 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 >Priority: Major > Fix For: JCR Resource 2.5.0, API 2.9.0, Resource Resolver 1.2.0 > > Attachments: SLING-848-metadata.patch > > Time Spent: 10m > Remaining Estimate: 0h > > 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 (v8.3.4#803005)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041485#comment-16041485
]
Alexander Klimetschek commented on SLING-848:
-
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
> 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040818#comment-16040818 ] Roy T. Fielding commented on SLING-848: --- To hopefully clarify, a path segment is each part between slash characters. I don't know if Sling has any use for parameters on hierarchical segments (e.g., versioned folders), but it would be odd for Sling to disallow them on parts of the URI it might not control. IOW, rule 1 might be OK but is overly restrictive for segments we don't own; 2 is just plain weird (if that is desired, use selectors instead of parameters); and both 3 and 4 are horribly ugly and unlikely to interop because many reference parsers will stop on single-quotes. Instead of single-quotes, it is better to append parameters and encode specific characters that we think might confuse data with delimiters. In general, URIs are meant to be LR parsed without any look-ahead for matching brackets/parens/quotes. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040768#comment-16040768
]
Tomek Rękawek commented on SLING-848:
-
The current state is as follows:
*1. Parameters has to be put at the end of the path*
Valid:
{noformat}
/content/mysite/page;foo=bar
{noformat}
Invalid:
{noformat}
/content/mysite;foo=bar/page
{noformat}
*2. Parameters can be put before or after extension*
{noformat}
/content/mysite/page;foo=bar.html
/content/mysite/page.html;foo=bar
{noformat}
*3. Single-quotes can be used to escape values*
{noformat}
/content/mysite/page;foo='bar'
/content/mysite/page;foo=bar
{noformat}
*4. Single-quotes has to be used to escape values containing dots, if the
parameters are specified before extension*
Valid:
{noformat}
/content/mysite/page.html;v=1.0
/content/mysite/page;v='1.0'.html
{noformat}
Invalid:
{noformat}
/content/mysite/page.html;v=1.0.html
{noformat}
If I understand correctly, the rule 1 is OK, but 2, 3 and 4 controversial and
[~fielding] suggestion is to get rid of them. In other words:
* parameters can only be put after extension,
* single-quotes can't be used to escape the parameter value,
* the path should be resolved in a "smart" way, so if there's a node matching
the path (even containing parameters), it should be used directly.
Is this right?
> 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040505#comment-16040505 ] Roy T. Fielding commented on SLING-848: --- Note that the semicolon-delimited syntax for path segment parameters was defined in RFC1808 because I wanted a reserved syntax to support versions. These parameters are supposed to be supplied at the end of a path segment, not arbitrarily in the middle. They are not specifically defined in RFC3986 because they are not needed for the generic syntax (scheme-independent parsing), but semicolons are reserved for this purpose. In other words, a path that contains a semicolon is supposed to be percent-encoded if it is not being used as a parameter delimiter. An "=" is not necessary (e.g., VMS files used a name;NN syntax). Of course, that is not going to help us for existing deployments if we are not automatically percent-encoding pathnames containing ";". We should have been doing that all along. I think the problem here is that the resolver is assuming that ";" indicates path parameters and then removes them from the path resolution. What it should be doing is either manage the segment names properly (meaning that a non-encoded ";" is impossible) or be smarter about matching the resource resolution so that ";" is allowable in unencoded form. IOW, what Alex said above. Also, filename extensions do not need to be at the end of path segments, and I certainly hope we aren't using single-quotes around parameter values because that isn't supported by any syntax. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040270#comment-16040270 ] Carsten Ziegeler commented on SLING-848: I personally think it is very unlike that one really has a node in the repository which contains both a semicolon and an equals sign..this sounds like a really terrible name to me. Looking at the quoted example, this really looks like a test string. So I'm wondering how likely this is to happen in real world. A new method just for the use case to pass in the version info has been discarded before and as you note, adding it now, doesn't really help as it will break current usage. I was thinking about your second solution as well, not sure if it is a good idea. But before we continue, can someone verify, that using a semicolon and equals sign in a url really works? > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039472#comment-16039472
]
Alexander Klimetschek commented on SLING-848:
-
The original filename that triggered this issue is actually
{{\_qwertyuiopasdfghjklzxcvbnm,.;'`1234567890-=~!@$^&(1)\_+'.jpg}}. It does
have an equals sign later in the string.
I could then also reproduce it with {{something;one=two}}.
It is _not_ reproduceable with {{something;else}}.
Agree with Carsten, OSGi configuration is not solving the issue. The Resource
API is typically used by many different application parts that wouldn't be able
to decide on a common configuration value.
Two ideas from my side:
1.
It seems to me only resolve() needs to handle these parameters with the
path/URL, as it is designed for passing through the raw URL path from a servlet
for example. A client using getResource() OTOH is programmatic and "knows" what
it's doing and could pass the parameters explicitly in a map, as proposed early
above in this issue by having an extra {{getResource(String path, String
versionName)}} or more generic {{getResource(String path, Map parameters)}}.
The only downside I can see is that adding a new method to the ResourceResolver
for this purpose might not be desirable to keep the interface simple to
understand for people new to Sling (and the resolve vs. getResource difference
is already a small trap). Furthermore, code that retrieves versioned resources
and relies on {{getResource()}} (can someone point me to an example?) would
have to switch - either to resolve() or the new {{getResource(String, Map)}}.
This raises the point of backwards compatibility, but I think it makes sense to
address the first regression (altering of the valid namespace).
And one problem we'd have to test: once this resource has been created, it
might be part of a URL and run as is through resolve(), and that should work as
well. Not sure if it would do...
2.
Maybe simply try to resolve the full path if the cut off path (if parameters
were found) doesn't resolve. (Not sure if that creates issues with different
permissions and the cut off path is not found due to missing read permission. A
getOrCreate style method might run into this, but likely would not be able to
create the full path variant then).
> 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038582#comment-16038582
]
Tomek Rękawek commented on SLING-848:
-
[~reschke]
bq. Source, please. All I can see in RFC 3986 is that ";" is in the reserved
set.
Sorry, you're right, RFC doesn't explicitly define this form of ;key=val
parameters, it's up to the application developers. Nevertheless, we've defined
such format in this JIRA.
bq. we have to be a little bit pragmatic here and not break people's code again.
Please notice that the parameters have worked in this way (looking for the
equals sign or passing the path as-is if it can't be found) for two years now,
since this issue has been resolved.
I think that the Alex'es example ({{parent.addNode("something;else")}}) is not
exact - it should include the equals sign somewhere. [~alexander.klimetschek] -
could you confirm if the example you've provided is really a way to reproduce
this issue?
> 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038557#comment-16038557 ] Carsten Ziegeler commented on SLING-848: [~reschke] While I agree that the proposal is not the nicest solution (I wrote that above already), we have to be a little bit pragmatic here and not break people's code again. If there is a better alternative, I'm all ears. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038545#comment-16038545 ] Julian Reschke commented on SLING-848: -- bq. The URI parameter format is defined by the RFC. Source, please. All I can see in RFC 3986 is that ";" is in the reserved set. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038505#comment-16038505 ] Tomek Rękawek commented on SLING-848: - bq. Making the semantics of ";" depend on whether it is followed by an equals sign IMHO is a hack. It just makes what happens even more obscure. I'm not sure about this. The URI parameter format is defined by the RFC. If an URI contains something that doesn't match the specification, it shouldn't be treated as a parameter. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038489#comment-16038489 ] Julian Reschke commented on SLING-848: -- Making the semantics of ";" depend on whether it is followed by an equals sign IMHO is a hack. It just makes what happens even more obscure. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038477#comment-16038477 ] Tomek Rękawek commented on SLING-848: - -I like the equals sign idea.- Actually, it works like this already :) Take a look on the [PathParserTest|https://github.com/apache/sling/blob/trunk/bundles/resourceresolver/src/test/java/org/apache/sling/resourceresolver/impl/params/PathParserTest.java#L152]. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038448#comment-16038448 ] Carsten Ziegeler commented on SLING-848: 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038406#comment-16038406 ] Tomek Rękawek commented on SLING-848: - [~alexander.klimetschek], according to the discussion in this JIRA, the semicolon parameters are supported both in the getResource() and resolve() methods (see [ResourceVersioningTest.java|https://github.com/apache/sling/blob/trunk/bundles/jcr/it-resource-versioning/src/test/java/org/apache/sling/jcr/resource/it/ResourceVersioningTest.java]). I can see 3 options here: * disable the parameters support in getResource(), * make the whole parameter support configurable, * make the getResource() parameters support configurable. > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038277#comment-16038277 ] Julian Reschke commented on SLING-848: -- Out of curiosity: will percent-escaping the semicolon disable the special handling? > 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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037662#comment-16037662
]
Alexander Klimetschek commented on SLING-848:
-
[~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)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14584478#comment-14584478 ] Tomek Rękawek commented on SLING-848: - I created a simple http test in the SLING-4804. It helped me discovering a bug, also fixed in the SLING-4804. The patch modifies the Sling Engine - it would be great if you can take a look on it. 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583385#comment-14583385 ] Carsten Ziegeler commented on SLING-848: [~tomek.rekawek] Are there any http based tests for this? 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14327250#comment-14327250 ] Tomek Rękawek commented on SLING-848: - Hello Stefan, I'm sorry that I did these changes in the \*mock modules without consulting you. Please find my reasons below: # This SLING-848 issue changes a few important modules: Sling API, Resource resolver and JCR resource provider. # I created an integration test it-resource-versioning # In this test I wanted to use sling-mock (as I need to mock the resource resolver) # I updated the Sling API, Resource resolver and JCR resource bundles in the sling-mock as I needed to have the new features from SLING-848 enabled in the mocked resolver. # I added the empty getThreadResourceResolver() as it was required by the new Sling API (it wasn't my change, but simply a thing that happened between Sling API 2.4.0 and 2.8.1-SNAPSHOT) # I needed the PathMapper for the similar reason - JcrResourceProviderFactory started referencing it in version 2.4.2 Now I see that I can solve point 4 and 5 without a need to modify the sling-mock, simply overriding versions of appropriate bundles in my it-resource-versioning/pom.xml, which I did in rev. 1660831. I still need the PathMapper to have the new JcrResourceProviderFactory working. I made a workaround in rev. 1660831, copying the MockJcrResourceResolverFactory to my testing module and adding PathMapper there. I think it's the only solution without updating jcr resource dependency in sling-mock to 2.4.2. 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: JCR 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14327365#comment-14327365 ] Tomek Rękawek commented on SLING-848: - I created SLING-4437. 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: JCR 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14327351#comment-14327351 ] Stefan Seifert commented on SLING-848: -- no problem, it was just not obvious to me that this ticket related the sling mock as well. please create a new sling ticket concerning sling mock to think about a better solution for point 6 without the code duplication, and reference it with this ticket. i will have to think about it. perhaps we can make MockJcrResourceResolverFactory ab bit more pluggable for this. i fear this is not the last time we will face such issues as the referenced/mocked bundles itself are further developed. 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: JCR 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14326688#comment-14326688
]
Stefan Seifert commented on SLING-848:
--
please note that in rev. 1660759 i reverted part of your change to sling mock
in rev. 1659489, 1658445:
* revert updating sling api/resource resolver/jcr resource dependenciens -
using sling mock in a project should not enforce using the latest version of
those
* keep adding of getThreadResourceResolver() method, but throw
UnsupportedOperationException
did you have a specific reason why you updated those dependencies?
i had to remove the line
{code:java}
bundleContext.registerService(PathMapper.class.getName(), new
PathMapper(), null);
{code}
in the mock JCR resource resolver factory as well, is it important, or can it
be added in projects using the latest sling api as well.
if we need to do special support for the latest apis we may have to branch the
sling mock code base, but i want to delay this as long as possible to avoid
maintaining multiple branches.
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: JCR
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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317924#comment-14317924
]
Tomek Rękawek commented on SLING-848:
-
Thanks for the feedback!
{quote}
I had a brief look at the applied code and I think the parameters are not added
to the metadata in all cases, e.g. if getResource(Resource, String) is called,
this calls getResourceInternal(String) which then calls
getAbsoluteResourceInternal.
{quote}
You are right.
{quote}
In general I think we should add the parameters to the metadata in all places
where we do a setResolutionPath or setResolutionPathInfo; but not in any other
place, which I think there is one or two in the source.
{quote}
Good idea, it'll make the metadata-related code more consistent. Please find
the patch attached.
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: JCR
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.1.14
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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317934#comment-14317934 ] Carsten Ziegeler commented on SLING-848: [~tomek.rekawek] Patch lgtm 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: JCR 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.1.14 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318233#comment-14318233 ] Tomek Rękawek commented on SLING-848: - I'll merge it as soon as I get my account working (now id.apache.org claims there is no such user as tomekr). 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: JCR 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312377#comment-14312377 ] ASF GitHub Bot commented on SLING-848: -- Github user trekawek closed the pull request at: https://github.com/apache/sling/pull/57 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: JCR Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Bertrand Delacretaz Fix For: JCR Resource 2.4.6, API 2.8.2, Resource Resolver 1.1.14 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303197#comment-14303197 ] Carsten Ziegeler commented on SLING-848: I had a brief look at the patch and it adds a new marker interface to the ResourcerResolver (to make it parameterizable). I can't clearly see why this is needed - and if possible we should avoid such additions to the resource api. 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: JCR Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Bertrand Delacretaz 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303209#comment-14303209 ] Carsten Ziegeler commented on SLING-848: Right, sorry, yes ResourceProvider it is :) What is currently in this map? 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: JCR Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Bertrand Delacretaz 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303213#comment-14303213
]
Tomek Rękawek commented on SLING-848:
-
All parameters parsed from the URI. For the URI like
{noformat}
/content/test;city=London;state=UK.html
{noformat}
it'll contain two values:
{noformat}
[city: London, state: UK]
{noformat}
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: JCR
Affects Versions: JCR Resource 2.0.2
Reporter: Carsten Ziegeler
Assignee: Bertrand Delacretaz
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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303202#comment-14303202
]
Tomek Rękawek commented on SLING-848:
-
Actually, it adds a new marker interface to the ResourceProvider. I think it's
compliant with the previous discussion:
{quote}
The sling resource resolver will extract uri parameters from the uri and pass
them to the resource providers in an additional parameter. Currently the
resource providers just get a path; we will extend this to be a path and a map
of all uri parameters.
The map of uri parameters will later on also end up in the resource meta data.
{quote}
In the first version I modified the ResourceProvider interface, but Bertrand
pointed out that it would be incompatible with existing ResourceProviders.
That's why there is the new ParametrizableResourceProvider.
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: JCR
Affects Versions: JCR Resource 2.0.2
Reporter: Carsten Ziegeler
Assignee: Bertrand Delacretaz
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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303220#comment-14303220 ] Carsten Ziegeler commented on SLING-848: Ok, thanks - I agree that passing this in the string will a) break existing providers and b) require reparsing in each provider. 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: JCR Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Bertrand Delacretaz 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.4#6332)
[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288340#comment-14288340
]
Tomek Rękawek commented on SLING-848:
-
Hello after 5 years :). I dug up this issue as it was mentioned in the recent
discussion on sling-users \[1] regarding support for the JCR versioning API in
Sling. It's also related to SLING-4318.
I prepared implementation of the feature described in this JIRA. It has been
published as a GitHub pull request \[2]. Please find description of the
proposed changes below:
h3. Parameters support in ResourceResolver
The first part of the implementation is the semicolon parameters support in
ResourceResolver and related classes. Methods getResource() and
resolveResource() are able to parse extract semicolon parameters, add them to
ResourceMetadata and pass to ResourceProvider as a MapString, String.
Following types of parameters are supported:
* /content/test;v='1.0'.html (after resource path, before extension)
* /content/test.html;v=1.0 (after extension, no need to escape dot with quotes)
It's possible to use several parameters in one URI:
* /content/test;v='1.0';x=abc.html (resulting map: \{v: 1.0, x: abc})
Parameters are removed from the path at an early stage of URI processing in
ResourceResolverImpl, so they shouldn't affect further path decomposition. Unit
test for the parser provides a complete specification \[3].
Parsing itself is done with two FSMs. The first one \[4] extracts the whole
parameter string from the URI so the second \[5] can split parameters into a
map. Besides from changes in o.a.s.resourceresolver bundle I had to make
following changes in the Sling API:
* there are new methods related to parameter map in ResourceMetadata,
* ResourceProvider#getResource() method takes a new argument (map of the
parameters).
h3. Versioning parameter in JcrResourceProvider
Now we can get the parameter map in the JcrResourceProvider and find an
appropriate version of the node. The lookup itself is done in
JcrResourceProvider#createResource() method. Following rules apply:
* /content/test;v='1.0' reads version 1.0 of the test node,
* /content/test/jcr:title;v='1.0' (where jcr:title is a property) reads version
1.0 of the test node and returns its jcr:title,
* /content/test/abc/xyz;v='1.0' (where abc and xyz are not versionable)
traverses the tree up until it finds a versionable node (=test) with version
1.0. Then appropriate subnode (abc/xyz) of the given version is returned.
* if there is no given version in versionable node or there is no versionable
ancestor, null is returned.
Because node passed to the JcrPropertyResource and JcrNodeResource are in fact
frozenNodes from the version storage, there are some changes in these classes,
related to getPath() method (we don't want to return
/jcr:system/jcr:versionStorage/... as a path or version number as a name). As a
result, path and name returned by the versioned resources have the ;v=
parameter appended at the end.
There is a module \[6] containing integration tests for the new behaviour,
working on a real JCR repository via sling-mock and sling-mock-jackrabbit. I
had to update dependency versions in two last modules, so they are aligned to
the latest Sling API.
I'm looking forward to feedback from the Sling community.
\[1] http://thread.gmane.org/gmane.comp.apache.sling.user/1610
\[2] https://github.com/apache/sling/pull/57
\[3] o.a.s.resourceresolver.impl.tree.params.PathParametersParserTest and
o.a.s.r.impl.MockedResourceResolverImplTest#testVersions()
\[4] o.a.s.resourceresolver.impl.tree.params.PathParser
\[5] o.a.s.resourceresolver.impl.tree.params.ParametersParser
\[6] o.a.s.jcr.repository.it-resource-versioning
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: JCR
Affects Versions: JCR Resource 2.0.2
Reporter: Carsten Ziegeler
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
