Mailing-List: contact dev-help@sling.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@sling.apache.org
Date: Tue, 6 Jun 2017 19:05:18 +0000 (UTC)
From: "Alexander Klimetschek (JIRA)" <jira@apache.org>
To: dev@sling.apache.org
Message-ID: <JIRA.12413860.1233653742000.9525.1496775918235@Atlassian.JIRA>
In-Reply-To: <JIRA.12413860.1233653742000@Atlassian.JIRA>
References: <JIRA.12413860.1233653742000@Atlassian.JIRA> <JIRA.12413860.1233653742447@jira-lw-us.apache.org>
Subject: [jira] [Commented] (SLING-848) Support getting versioned resources
 by using uri path parameters
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 06 Jun 2017 19:05:24 -0000


    [ https://issues.apache.org/jira/browse/SLING-848?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16039=
472#comment-16039472 ]=20

Alexander Klimetschek commented on SLING-848:
---------------------------------------------

The original filename that triggered this issue is actually {{\_qwertyuiopa=
sdfghjklzxcvbnm,.;'`1234567890-=3D~!@$^&(1)\_+'.jpg}}. It does have an equa=
ls sign later in the string.

I could then also reproduce it with {{something;one=3Dtwo}}.

It is _not_ reproduceable with {{something;else}}.

Agree with Carsten, OSGi configuration is not solving the issue. The Resour=
ce 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 pat=
h/URL, as it is designed for passing through the raw URL path from a servle=
t 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 pro=
posed early above in this issue by having an extra {{getResource(String pat=
h, String versionName)}} or more generic {{getResource(String path, Map par=
ameters)}}.

The only downside I can see is that adding a new method to the ResourceReso=
lver for this purpose might not be desirable to keep the interface simple t=
o understand for people new to Sling (and the resolve vs. getResource diffe=
rence is already a small trap). Furthermore, code that retrieves versioned =
resources and relies on {{getResource()}} (can someone point me to an examp=
le?) would have to switch - either to resolve() or the new {{getResource(St=
ring, Map)}}. This raises the point of backwards compatibility, but I think=
 it makes sense to address the first regression (altering of the valid name=
space).

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 wor=
k as well. Not sure if it would do...

2.
Maybe simply try to resolve the full path if the cut off path (if parameter=
s were found) doesn't resolve. (Not sure if that creates issues with differ=
ent permissions and the cut off path is not found due to missing read permi=
ssion. 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=C4=99kawek
>             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=3D1.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 meth=
od which removes all uri path parameters
> and returns a map of these. Every resource provider could use this utilit=
y 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, an=
d 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)