[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
