Re: Restrict access to the content under a given node
Hi Rory, On Mon, Feb 2, 2009 at 16:20, Rory Douglas rory.doug...@oracle.com wrote: Actually, currently in the HTTP Basic AuthHandler in the authenticate() method, the code looks for a request parameter 'sling:authRequestLogin' (value doesn't matter). If it finds it, the handler actually calls the requestAuthentication() method on itself. So you can force at the HTTP Auth login box to be displayed by just appending that param to your intended target URL. If you've already authenticated via HTTP BASIC, the request passes through directly to the target resource. Could this perhaps be generalized somehow? Perhaps moved into the SlingAuthenticator? I tried to access my content with the parameter 'sling:authRequestLogin', but I haven't got any credentials request and the HTTP error code returned was the same for the request without the parameter. Does this feature depends somehow on the allow anonymous access configuration? Another thing I noticed is that when I access the system console, I'm prompted for credentials. Isn't possible to reuse the logic that protects the contents under /system/console? Is this protection configured in Sling or is it Felix related? Kind regards, -- Douglas Jose http://douglasjose.com - Use free software. Help us make a free world.
[jira] Commented: (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=12669986#action_12669986 ] Andreas Hartmann commented on SLING-848: A problem with predefined parameter names is that they restrict the available space for application parameter names. In Lenya, we prefix all framework-level request parameters with lenya., e.g. for revisions we use lenya.revision=xyz. I'm not sure if this also applies to URI path parameters, though. 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 Install Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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=12669988#action_12669988 ] Tobias Bocanegra commented on SLING-848: but do you want to add this to the resource resolver, or the request resolver? so should a ResourceResolver.getResource(/something/hello;v=1.1) return a different version? or should a request to /something/hello.html;v=1.1 trigger a resource resolution to the respective version? (which eventually needs the former, too) 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 Install Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SlingAuthenticator with multiple Handlers for same path prefix
On Sun, Feb 1, 2009 at 2:27 AM, Rory Douglas rory.doug...@oracle.com wrote: When multiple AuthenticationHandlers are registered for a given path prefix, the SlingAuthenticator tries each one in turn until one returns an AuthenticationInfo object. There is no way to control the order in which the handlers are tried. A solution that is sub-optimal, but at least gives you full control and works with current Sling, is simply to write your custom authentication handler that handles all cases in the correct order. For example, if you want to handle OpenID and fall back to HTTP Basic Auth if no OpenID is available, you could subclass from the existing basic auth handler; in there you call/check for OpenID auth first and call the super implementation if no OpenID is available. This way you can also handle corner-cases where two authentication schemes might overlap in some way. But I would still opt for re-use of existing classes through simple configuration, most cases are probably rather simple and just require the proper order. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: SlingAuthenticator with multiple Handlers for same path prefix
I've been using the priority ordering method locally for a while and it works OK, but I agree that it might not always be flexible enough to handle corner cases. The more I think about it, the more I feel the authentication handlers should be registered with applicable virtual hosts (as Felix suggested earlier). I'm not sure that multiple handlers for a given virtual host path would be a very common scenario - more common would be the following (assuming an appropriately secured network/DMZ): http://public.my.site.com - requires some kind of SSO, OpenID etc http://admin.my.site.com - uses only HTTP Basic auth, for content updates via cURL etc, perhaps only visible to local network It would be nice to hook into the existing Virtual Host support, by just registering the appropriate handlers for the mapped virtual paths (e.g http://public.my.site.com - /content/public/site), but I think request authentication is performed only on the originally requested URL, not any translations/mapping internal to Sling, correct? In that case, perhaps we could just modify the AuthenticationHandler PATH property handling in SlingAuthenticator to allow including the virtual hostname and even the protocol for matching purposes? So the following would apply: Path=/ Applies to: all URLs across all virtual hosts (1) Path=//public.my.site.com/ Applies to: all URLs on the public.my.site.com host (2) Path=//public.my.site.com/protected Applies to: URLs starting with /protected on public.my.site.com host (3) Path=https://public.my.site.com/protected/personalinfo/ Applies to: URLs starting with /protected/personalinfo on public.my.site.com host under SSL (4) The priority ordering would work from most specific to most general, so above (4) would have priority over (3), (3) over (2) etc. This could be implemented by changing getAuthenticationHandlers() method to return a MapString, MapString, AuthenticationHandlerInfo[] - the first lookup is by protocol, the second by hostname, the last by path. How does that sound? Regards, Rory Alexander Klimetschek wrote: On Sun, Feb 1, 2009 at 2:27 AM, Rory Douglas rory.doug...@oracle.com wrote: When multiple AuthenticationHandlers are registered for a given path prefix, the SlingAuthenticator tries each one in turn until one returns an AuthenticationInfo object. There is no way to control the order in which the handlers are tried. A solution that is sub-optimal, but at least gives you full control and works with current Sling, is simply to write your custom authentication handler that handles all cases in the correct order. For example, if you want to handle OpenID and fall back to HTTP Basic Auth if no OpenID is available, you could subclass from the existing basic auth handler; in there you call/check for OpenID auth first and call the super implementation if no OpenID is available. This way you can also handle corner-cases where two authentication schemes might overlap in some way. But I would still opt for re-use of existing classes through simple configuration, most cases are probably rather simple and just require the proper order. Regards, Alex
[jira] Commented: (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=12670026#action_12670026 ] Carsten Ziegeler commented on SLING-848: @Andreas: I don't think that we have to prefix the uri path parameters. The parameter is used to get the corresponding representation of the resource and I think it's unlikely that someone else is using the same at the same time. @Tobias: The check is added to the jcr resource provider which provides the resource for a given path (being it the path from the http request or a path passed in to the resource resolver). So we can handle this transparently in the resource provider. Noone else is affected by this. 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 Install Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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=12669953#action_12669953 ] Tobias Bocanegra commented on SLING-848: you mean: something/hello.html;v=1.1 ? this will set a resource resolver option v=1.1 ? so in general, the resource resolver should have a new method: getResource(String path, Sring versionName) or should there be a 'VersionSelector' interface, that is resposible to select the proper version for a requested path? 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 Install Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-849) Enhance SlingAuthenticator's handler selection mechanism
Enhance SlingAuthenticator's handler selection mechanism Key: SLING-849 URL: https://issues.apache.org/jira/browse/SLING-849 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.0.2 Reporter: Rory Douglas Priority: Minor Currently, AuthenticationHandlers can only be registered by path. It would be useful to be able to register them with additional attributes, in particular hostname, to enable different authentication mechanisms for different virtual hosts. It may also be useful to indicate a priority, for ordering purposes when 2 or more handlers are registered for the same set of attributes (path, hostname etc). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue 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=12670136#action_12670136 ] tripod edited comment on SLING-848 at 2/3/09 2:06 PM: so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg: /content/home;v=1.0/tobi;v=1.5 (assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home') what is the external form of this?, probably: /content/home;v=1.0/tobi.html;v=1.5 having the .html at the end makes no sense. but this makes every script logic that just appends the .html to the resource path pretty useless. the problem you have is: - if you include the v= to the resource.getPath() the resource gets unusable for normal scripts, - if you omit it from the path, the getResource() / getPath() is not symmetric so maybe this is not such a good idea after all? btw: i think the component of this issue is wrong. was (Author: tripod): so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg: /content/home;v=1.0/tobi;v=1.5 (assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home') what is the external form of this?, probably: /content/home;v=1.0/tobi.html;v=1.5 having the .html at the end makes no sense. but this makes each script logic that just appends the .html to the resource path pretty useless. the problem you have is: - if you include the v= to the resource.getPath() the resource gets unusable for normal scripts, - if you omit it from the path, the getResource() / getPath() is not symmetric so maybe this is not such a good idea after all? btw: i think the component of this issue is wrong. 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 Install Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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=12670136#action_12670136 ] Tobias Bocanegra commented on SLING-848: so consequently (according to rfc3986) , the v= parameter should be applicable to each segment. eg: /content/home;v=1.0/tobi;v=1.5 (assuming /content/home/tobi is currently deleted and did only exist in the version 1.0 of the 'home') what is the external form of this?, probably: /content/home;v=1.0/tobi.html;v=1.5 having the .html at the end makes no sense. but this makes each script logic that just appends the .html to the resource path pretty useless. the problem you have is: - if you include the v= to the resource.getPath() the resource gets unusable for normal scripts, - if you omit it from the path, the getResource() / getPath() is not symmetric so maybe this is not such a good idea after all? btw: i think the component of this issue is wrong. 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 Install Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: JCR Resource 2.0.4 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-849) Enhance SlingAuthenticator's handler selection mechanism
[ https://issues.apache.org/jira/browse/SLING-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Douglas updated SLING-849: --- Attachment: SlingAuthenticator.java I've extended the current AuthenticationHandler.PATH property processing to include handling of hostname and protocol. Only the SlingAuthenticator is affected by this change. Existing path registrations (starting with '/') will work as-is. New mappings are possible: //hostname //hostname:port //hostname/path http://hostname https://hostname:port/path etc Enhance SlingAuthenticator's handler selection mechanism Key: SLING-849 URL: https://issues.apache.org/jira/browse/SLING-849 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.0.2 Reporter: Rory Douglas Priority: Minor Attachments: SlingAuthenticator.java Currently, AuthenticationHandlers can only be registered by path. It would be useful to be able to register them with additional attributes, in particular hostname, to enable different authentication mechanisms for different virtual hosts. It may also be useful to indicate a priority, for ordering purposes when 2 or more handlers are registered for the same set of attributes (path, hostname etc). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CRX 1.4.1 released - powered by Apache Jackrabbit Sling - thanks!
Hi Michael On Mon, Feb 2, 2009 at 4:13 PM, Michael Wechner michael.wech...@wyona.com wrote: with all respect for Day and in particular the various Apache devs working at Day, but it seems to me that your email is just a nicely packaged spam message Sorry you feel this way. I did want to thank the whole community, I have thanked the Day engineering team in an internal email. I honestly admit I wanted to let people know... being prod. manager for the product and all. I could have left out links to the release update blog, the interested would have found out anyway. Interesting question whether/under which condition would release announcements be considered spam. I'll ask that separately, I think announcements like this might be more interesting to users@ lists, if the community's ok with that. Cheers, Greg PS. Michael, I have to admit I have, post mortem, found your post re 'devs for fire'... nasty me ;) MfG, G.
[jira] Updated: (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:all-tabpanel ] Carsten Ziegeler updated SLING-848: --- Component/s: (was: JCR Install) JCR Resource Fix Version/s: (was: JCR Resource 2.0.4) Assignee: (was: Carsten Ziegeler) 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 Resource Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to use job (timing task) in sling
Hi everyone: I found sling handles jobs base on Quartz however I didn't use it before , as a result it's a little difficult for me to grasp it in short time . And can anyone tell me how to use it even a simple example such as print a hello per 5 minutes ? Thanks . 2009-02-04 yanjie
Re: How to use job (timing task) in sling
yanshaozhiGmail wrote:
Hi everyone:
I found sling handles jobs base on Quartz however I didn't use it before ,
as a result it's a little difficult for me to grasp it in short time .
And can anyone tell me how to use it even a simple example such as print a
hello per 5 minutes ?
Thanks .
What do you want to do? Schedule something periodically or at given time?
First, you need the commons scheduler bundle of course. The easiest way
to schedule something is to register a service with OSGi which
implements the java.lang.Runnable interface and has a configuration
property to specify how to schedule this service.
For example if you use SCR with the maven scr plugin:
/**
* @scr.component
* @scr.service interface=java.lang.Runnable
* @scr.property name=scheduler.period value=300 type=Long
*/
public class MyClass implements Runnable {
public void run() {
System.out.println(Hello World!);
}
}
You can either run the job periodically like in the example above
or specify the scheduler.expression property with a cron expression.
If you need more control, you can use the
org.apache.sling.commons.scheduler.Scheduler service to add and remove jobs.
HTH
Carsten
--
Carsten Ziegeler
cziege...@apache.org
[jira] Commented: (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=12670266#action_12670266 ] Felix Meschberger commented on SLING-848: - Yes, according to rfc3986 /content/home;v=1.0/tobi;v=1.5 would be perfectly valid. But we won't support it, since this leads into areas which are too complicated to grasp and which can almost not be described. For this reason, we define, that the ;v= URI parameter is only recognized and used on the last segment. Now, for the location of the ;v= specification. The intened location is of course to be at the end, as in /content/home/tobi.html;v=1.5 If we would have Resource.getPath() include the ;v= we would of course also have to support things like /content/home/tobi;v=1.5.selector.html You are right, that this is neither nice nore very logic, though not necessairily violating the spec. Maybe we should think about this some more. btw: i think the component of this issue is wrong. Probably yes, but this is the only component available currently for treating ResourceResolver issues. We should probably create another one -- also in light of the proposed extension of the ResourceResolver infrastructure. 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 Resource Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue 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=12670266#action_12670266 ] fmeschbe edited comment on SLING-848 at 2/3/09 11:25 PM: -- Yes, according to rfc3986 /content/home;v=1.0/tobi;v=1.5 would be perfectly valid. But we won't support it, since this leads into areas which are too complicated to grasp and which can almost not be described. For this reason, we define, that the ;v= URI parameter is only recognized and used on the last segment. Now, for the location of the ;v= specification. The intened location is of course to be at the end, as in /content/home/tobi.html;v=1.5 If we would have Resource.getPath() include the ;v= we would of course also have to support things like /content/home/tobi;v=1.5.selector.html You are right, that this is neither nice nore very logic, though not necessairily violating the spec. Maybe we should think about this some more. was (Author: fmeschbe): Yes, according to rfc3986 /content/home;v=1.0/tobi;v=1.5 would be perfectly valid. But we won't support it, since this leads into areas which are too complicated to grasp and which can almost not be described. For this reason, we define, that the ;v= URI parameter is only recognized and used on the last segment. Now, for the location of the ;v= specification. The intened location is of course to be at the end, as in /content/home/tobi.html;v=1.5 If we would have Resource.getPath() include the ;v= we would of course also have to support things like /content/home/tobi;v=1.5.selector.html You are right, that this is neither nice nore very logic, though not necessairily violating the spec. Maybe we should think about this some more. btw: i think the component of this issue is wrong. Probably yes, but this is the only component available currently for treating ResourceResolver issues. We should probably create another one -- also in light of the proposed extension of the ResourceResolver infrastructure. 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 Resource Affects Versions: JCR Resource 2.0.2 Reporter: Carsten Ziegeler 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
