[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17777179#comment-17777179
]
Manfred Baedke edited comment on JCR-4954 at 10/19/23 10:28 AM:
----------------------------------------------------------------
[~c_koell], after staring at the code for quite some time I came to the
conclusion that we actually have two independent issues: the first problem is
that the LockTokenMapper should not add a prefix to a LockToken that is already
prefixed. The second problem is that the JcrRemotingServlet at some point
creates a LockImpl with an internal flag that it needs a refresh, but the
refresh would only happen as a side effect of a method that never gets called.
That means that the lock is attached to the wrong session, which makes the
LockTokenMapper unable to read the lock token. Both issues are hopefully
addressed in the attached experimental
[patch|https://issues.apache.org/jira/secure/attachment/13063696/jcr-4954-diagnose.patch]
. Could you try if it helps?
was (Author: baedke):
[~c_koell], after staring at the code for quite some time I came to the
conclusion that we actually have two independent issues: the first problem is
that the LockTokenMapper should not add a prefix to a LockToken that is already
prefixed. The second problem is that the JcrRemotingServlet at some point
creates a LockImpl with an internal flag that it needs a refresh, but the
refresh would only happen as a side effect of a method that never gets called.
That means that the lock is attached to the wrong session, which makes the
LockTokenMapper unable to read the lock token. Both issues are hopefully
addressed in the attached experimental patch. Could you try if it helps?
> Problem with WebDav Client and Repository Server Deployment Model
> -----------------------------------------------------------------
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
> Reporter: Claus Köll
> Assignee: Manfred Baedke
> Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt,
> SimpleWebDavServlet.txt, config.xml, jcr-4954-diagnose.patch
>
>
> We have one WebApp where we have deployed the SimpleWebDavServlet
> (WebDav-WebApp). From there we connect to a other WebApp where we have
> exposed a Repository through DavEx
> (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet)
> and also the RMI-Layer by the RMI Registry (Repository-WebApp)
> Until now we connected over RMI but now we tried to switch to DavEx. The
> Problem is, that we are now unable to unlock a opened WebDav Document.
> The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the
> DavSession so a future Requests can obtain the same DavSession to perform the
> unlock.
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700
> The Reference (Locktoken) looks like
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> It will be generated by the LockTokenMapper
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53
> In the WebDav-WebApp the HeaderLockToken will be stored in this format
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4
> As you can see it will be double wrapped. That's not really a Problem because
> on unlock the WebDav-WebApp removes the prefix
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:
> Finally this locktoken will be send from the WebDav-App to the
> Repository-WebApp
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> On the Repository-WebApp the JCRWebdavServer will look for a DavSession in
> the Cache based on the lockToken
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210
> So the problem is that the DavSession whitch have created the Lock, is stored
> with a lockToken that do not match with the incoming lockToken
> Cache-Key-Token:
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> Incoming-Token:
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is
> present)
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118
> Maybe someone which is familiar with the code of LockTokenMapper can explain
> the two different Scopes (SESSIONSCOPED/OPENSCOPED)
> One possible solution could be to change the code in the LockTokenMapper to
> always return the Node Identifier with the same SCOPE-PREFIX?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
