[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786368#comment-17786368
]
Claus Köll commented on JCR-4954:
---------------------------------
[~baedke] you are right .. i do not really understand this complex layer
construct :)
I have tried the following change of your patch
{code:java}
org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java
...
lock.getLockToken();
...{code}
and checked the reloadInfo flag. The value is true in the Constructor of
LockImpl and the LockInfo will be loaded again in
#{color:#000000}getLockToken(){color} on Server A which ends up with a PROPFIND
lockDiscovery Request to Server B.
{code:java}
Request Method [PROPFIND] ->
/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc
Request-Payload [<?xml version="1.0" encoding="UTF-8"?><D:propfind
xmlns:D="DAV:"><D:prop><D:lockdiscovery/><dcr:parent
xmlns:dcr="http://www.day.com/jcr/webdav/1.0"/></D:prop></D:propfind>
]
Response Method [PROPFIND] ->
/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc
Response-Payload [<?xml version="1.0" encoding="UTF-8"
standalone="no"?><D:multistatus
xmlns:D="DAV:"><D:response><D:href>http://localhost:9080/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc/</D:href><D:propstat><D:prop><D:lockdiscovery><D:activelock><D:lockscope><D:exclusive/></D:lockscope><D:locktype><D:write/></D:locktype><D:depth>infinity</D:depth><D:timeout>Second-3443</D:timeout><D:owner>LV\udvt0047</D:owner><D:locktoken><D:href>opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:6007b5ba-b2c2-4bd1-8a27-9457a39a5ba7</D:href></D:locktoken><D:lockroot><D:href>http://localhost:9080/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/46b237050a0a80969a8156c54ced1b37.doc</D:href></D:lockroot></D:activelock></D:lockdiscovery><dcr:parent
xmlns:dcr="http://www.day.com/jcr/webdav/1.0";><D:href>http://localhost:9080/jcr/server/template/jcr%3aroot/tirolgvat/2016/9/4/2/10/24/</D:href></dcr:parent></D:prop><D:status>HTTP/1.1
200 OK</D:status></D:propstat></D:response></D:multistatus>]{code}
As you can see, Server B sends back following LockToken.
{noformat}
opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:6007b5ba-b2c2-4bd1-8a27-9457a39a5ba7
{noformat}
This is not the real Locktoken from the locked Node on Server B. It is the
UUID. I have explained this behaviour in my previous comment. See the Code of
LockTokenMapper
{code:java}
org.apache.jackrabbit.webdav.jcr.lock.LockTokenMapper.java
public static String getDavLocktoken(Lock lock) throws RepositoryException {
String jcrLockToken = lock.getLockToken();
if (jcrLockToken == null) {
return SESSPREFIX + Text.escape(lock.getNode().getIdentifier());
} else {
return OPENPREFIX + Text.escape(jcrLockToken);
}
} {code}
So AFAICS the problem is on Server B because it does not return the same
LockToken on LOCK Request respectively on PROPFIND (lockDiscovery) Request.
> 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,
> JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.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)
