[ 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)