[jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters

["Tomek Rękawek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 Map<String, 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 does not have the requested version or the child, a 404 is returned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)