[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039472#comment-16039472
]
Alexander Klimetschek edited comment on SLING-848 at 6/6/17 8:52 PM:
---------------------------------------------------------------------
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 value.
Two ideas from my side:
1.
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 do...
2.
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).
was (Author: alexander.klimetschek):
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 value.
Two ideas from my side:
1.
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 do...
2.
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: 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ę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.15#6346)
