[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041485#comment-16041485
]
Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
-
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
Although I think it's still a problem of mixing URLs (where these parameters
come in) and the resource namespace, which came in by sharing the same
implementation (getResourceInternal) between resolve() and getResource(), while
it should probably be separated, so the parameter parsing happens for resolve()
only and other means given to retrieve things with parameter if you are a
client using getResource() semantics.
was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered). Although I think it's still a problem of mixing URLs (where these
parameters come in) and the resource namespace, which came in by sharing the
same implementation (getResourceInternal) between resolve() and getResource(),
while it should probably be separated, so the parameter parsing happens for
resolve() only and other means given to retrieve things with parameter if you
are a client using getResource() semantics.
> 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
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16041485#comment-16041485
]
Alexander Klimetschek edited comment on SLING-848 at 6/7/17 7:34 PM:
-
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered). Although I think it's still a problem of mixing URLs (where these
parameters come in) and the resource namespace, which came in by sharing the
same implementation (getResourceInternal) between resolve() and getResource(),
while it should probably be separated, so the parameter parsing happens for
resolve() only and other means given to retrieve things with parameter if you
are a client using getResource() semantics.
was (Author: alexander.klimetschek):
[~cziegeler] {quote}Looking at the quoted example, this really looks like a
test string. So I'm wondering how likely this is to happen in real world.{quote}
Yes, it's a test string, and I agree it should be pretty rare.
*However*, my experience tells me that especially at such a fundamental layer
as the resource API, rare or not rare is not something you can decide as the
framework provider and it might even change over time. What if someone actually
stores names with such parameters deliberately as resources for some
meta-reason? There is also no other restriction that the resource API imposes
on names (other than slashes as path delimiters) as far as I know, and this
case seems not strong enough to start imposing a limit after the API has
existed for ~7 years (before this change). Hence I think these names should be
safely supported.
Furthermore, it isn't even clearly documented anywhere, and as the discussion
shows, we don't have an exact description of the format and what an "invalid"
resource path would be, assuming nothing is changed.
I would look at option 2 and see if that works (after the general questions are
answered).
> 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)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039472#comment-16039472
]
Alexander Klimetschek edited comment on SLING-848 at 6/6/17 8:53 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 retrieve the resource with the full path if the cut off
path (if parameters were found) doesn't return a resource.
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:
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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,
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
>
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[ https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038448#comment-16038448 ] Carsten Ziegeler edited comment on SLING-848 at 6/6/17 9:31 AM: I don't think a configuration would work as this means its either on or off, so as soon as you have both use cases, you're in a dead end. But I would like to understand the problem space a little bit more. If your resource path is using a semicolon and you're using this in a url, you have to encode it - this has always been the case as the semicolon denotes uri parameters and these are stripped off by servlet engines like jetty. With the implementation of this issue, we just use the uri parameter to get the version, so we're using additional information. When implementing this additional support we decided to support the same syntax in getResource() to allow to get a version of a resource. Otherwise there would be no way to specify this. Now, if we revert something we did for this issue, we break other peoples code using exactly that feature. On the other hand, getResource() should not have magic, as it should use the path as is. Maybe there is any easy way out, the paths we care for are of this sort: /content/test;v='1.0' so there is a name and a value. Based on that , we could change getResource into: - no semicolon : use path as is - semicolon but no equals sign in uri parameter, use path as is - semicolon and equals sign, use as (version) parameter While this is maybe not the easiest to understand, it will implement both use cases without a configuation. And as the quick check is checking for a semicolon, there shouldn't be a performance penality And potentially we should implement the same logic in resolve() was (Author: cziegeler): I don't think a configuration would work as this means its either on or off, so as soon as you have both use cases, you're in a dead end. But I would like to understand the problem space a little bit more. If your resource path is using a semicolon and you're using this in a url, you have to encode it - this has always been the case as the semicolon denotes uri parameters and these are stripped off by servlet engines like jetty. With the implementation of this issue, we just use the uri parameter to get the version, so we're using additional information. When implementing this additional support we decided to support the same syntax in getResource() to allow to get a version of a resource. Otherwise there would be no way to specify this. Now, if we revert something we did for this issue, we break other peoples code using exactly that feature. On the other hand, getResource() should not have magic, as it should use the path as is. Maybe there is any easy way out, the paths we care for are of this sort: /content/test;v='1.0' so there is a name and a value. Based on that , we could change getResource into: - no semicolon : use path as is - semicolon but no equals sign in uri parameter, use path as is - semicolon and equals sign, use as (version) parameter While this is maybe not the easiest to understand, it will implement both use cases without a configuation. And as the quick check is checking for a semicolon, there shouldn't be a performance penality > 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)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037662#comment-16037662
]
Alexander Klimetschek edited comment on SLING-848 at 6/5/17 9:56 PM:
-
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names. We (Adobe AEM) have a lot of code that
works like this and now fails if a ";" is included in the path:
{code:java}
Node node = parent.addNode("something;else");
Resource resource = resourceResolver.getResource(node.getPath());
{code}
I wonder if all Resource creation APIs and utilities within Sling are also
adapted consistently at this point?
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
was (Author: alexander.klimetschek):
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
> 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)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037662#comment-16037662
]
Alexander Klimetschek edited comment on SLING-848 at 6/5/17 9:51 PM:
-
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
This creates a problem for application code creating resources through another
API (such as JCR) that is not aware of this semantic, or for existing content
that includes ";" in resource names.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
was (Author: alexander.klimetschek):
[~tomek.rekawek] [~cziegeler]
This change looks like it makes it impossible to read resources containing a
";" in their name via getResource(path). In case of the JCR resource provider,
these can be created via the JCR API.
This is because a path like {{/content/something;else}} will be parsed as
{{/content/something}} in getResource(path) (within getResourceInternal()) and
thus not found. I am using 1.5.22 of org.apache.sling.resourceresolver.
IIUC, this type of parameter parsing for URLs should only be done in resolve(),
but not in getResource()?
> 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)
[jira] [Comment Edited] (SLING-848) Support getting versioned resources by using uri path parameters
[
https://issues.apache.org/jira/browse/SLING-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317924#comment-14317924
]
Tomek Rękawek edited comment on SLING-848 at 2/12/15 10:02 AM:
---
Thanks for the feedback!
{quote}
I had a brief look at the applied code and I think the parameters are not added
to the metadata in all cases, e.g. if getResource(Resource, String) is called,
this calls getResourceInternal(String) which then calls
getAbsoluteResourceInternal.
{quote}
You are right.
{quote}
In general I think we should add the parameters to the metadata in all places
where we do a setResolutionPath or setResolutionPathInfo; but not in any other
place, which I think there is one or two in the source.
{quote}
Good idea, it'll make the metadata-related code more consistent. Please find
the patch attached (SLING-848-metadata.patch).
was (Author: tomek.rekawek):
Thanks for the feedback!
{quote}
I had a brief look at the applied code and I think the parameters are not added
to the metadata in all cases, e.g. if getResource(Resource, String) is called,
this calls getResourceInternal(String) which then calls
getAbsoluteResourceInternal.
{quote}
You are right.
{quote}
In general I think we should add the parameters to the metadata in all places
where we do a setResolutionPath or setResolutionPathInfo; but not in any other
place, which I think there is one or two in the source.
{quote}
Good idea, it'll make the metadata-related code more consistent. Please find
the patch attached.
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.1.14
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)
