[ 
https://issues.apache.org/jira/browse/JCR-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187704#comment-13187704
 ] 

Julian Reschke edited comment on JCR-3209 at 7/19/23 11:43 AM:
---------------------------------------------------------------

Angela, sorry for missing the two older JIRA issues :-) Will clean this up.

Regarding:

"> This will likely cause requests to fail that use both types of locks (yes, 
maybe academic but should be fixed anyway) can't follow you here. "

My reading of the code is that a RuntimeException is thrown and thus the 
request will not continue to run as it should (but I'll check that).


was (Author: reschke):
Angela, sorry for missing the two older JIRA issues :-) Will clean this up.

Regarding:

"> This will likely cause requests to fail that use both types of locks (yes, 
maybe academic but should be fixed anyway)

can't follow you here. "

My reading of the code is that a RuntimeException is thrown and thus the 
request will not continue to run as it should (but I'll check that).

> lock token validity
> -------------------
>
>                 Key: JCR-3209
>                 URL: https://issues.apache.org/jira/browse/JCR-3209
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr-server, jackrabbit-spi2dav, locks
>    Affects Versions: 2.4.4
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>            Priority: Minor
>             Fix For: 2.4.5, 2.5
>
>         Attachments: JCR-3209.diff
>
>
> There are several minor issues in the mapping between JCR lock tokens and 
> WebDAV lock tokens:
> 1) WebDAV lock tokens are supposed to use URI syntax (such as 
> opaquelocktoken: or urn:uuid:)
> 2) The server currently computes lock tokens for session-scoped locks based 
> on the node id; these are not valid JCR lock tokens though and cause 
> exceptions when they are re-added when they appear in a Lock-Token header or 
> an If header. This will likely cause requests to fail that use both types of 
> locks (yes, maybe academic but should be fixed anyway)
> Proposal:
> a) Map lock tokens to oqaquelocktoken URIs, using a constant UUID plus a 
> postfix encoding the original lock token
> b) Use a syntax that allows to distinguish between tokens for open-scoped 
> locks or session-scoped locks, so that we do not try to add the latter type 
> to the Session (alternatively, handle exceptions doing so gracefully)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to