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