sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <>
Subject [jira] [Commented] (SLING-848) Support getting versioned resources by using uri path parameters
Date Tue, 06 Jun 2017 19:05:18 GMT


Alexander Klimetschek commented on SLING-848:

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

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

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

Agree with Carsten, OSGi configuration is not solving the issue. The Resource API is typically
used by many different application parts that wouldn't be able to decide on a common configuration

Two ideas from my side:

It seems to me only resolve() needs to handle these parameters with the path/URL, as it is
designed for passing through the raw URL path from a servlet 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 proposed early above in this issue by having an extra {{getResource(String path,
String versionName)}} or more generic {{getResource(String path, Map parameters)}}.

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

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 work as well. Not sure if it would

Maybe simply try to resolve the full path if the cut off path (if parameters were found) doesn't
resolve. (Not sure if that creates issues with different permissions and the cut off path
is not found due to missing read permission. 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:
>             Project: Sling
>          Issue Type: New Feature
>          Components: API, JCR, ResourceResolver
>    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

View raw message