[
https://issues.apache.org/jira/browse/JCR-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187690#comment-13187690
]
angela commented on JCR-3209:
-----------------------------
isn't 1) already covered by JCR-1352?
regarding 2)
> The server currently computes lock tokens for session-scoped locks based on
> the node id; these are not valid JCR lock tokens though
this change was introduce since as of jcr 2.0 session scoped locks don't expose
the token any more.
if you have a proposal for another type of token that's fine.
> and cause exceptions when they are re-added when they appear in a Lock-Token
> header or an If header.
as far as i know this just causes a ugly warning in the log file (written by
jackrabbit-core), since adding the token to
session fails, which in this case was useless any way as they are session
scoped. but if i remember correctly it otherwise
used to work (see also JCR-2990... which i resolved wontfix due to lack of
priority)
> 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.
but anyway: it was definitely favorable if we can distinguish the two types of
locks based on the token and
could therefore omit adding it to the session/lockmanager.
> lock token validity
> -------------------
>
> Key: JCR-3209
> URL: https://issues.apache.org/jira/browse/JCR-3209
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-jcr-server, jackrabbit-spi2dav, locks
> Reporter: Julian Reschke
> Priority: Minor
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
