[ https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776581#comment-17776581 ]
Claus Köll edited comment on JCR-4954 at 10/18/23 9:51 AM: ----------------------------------------------------------- I have now implemented a WebFilter on both servers.. now we have a full trace of all http requests. On Server Server-A is configured a SimpleWebDavServlet. You can see the request/response from MSOffice-Word in the [^SimpleWebDavServlet.txt] File The Remote Repository URL to Server-B looks like [http://localhost:9080/jcr/server.] On Server-B is configured a JcrRemotingServlet. You can also see the request/response in [^JcrRemotingServlet.txt] File. Regarding configuration ... On Server-A the SimpleWebDavServlet is configured like following {code:java} <servlet> <description>The webdav servlet that connects HTTP request to the repository.</description> <servlet-name>WebdavServlet</servlet-name> <servlet-class>org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet</servlet-class> <init-param> <param-name>resource-path-prefix</param-name> <param-value>/repository</param-value> </init-param> <init-param> <param-name>authenticate-header</param-name> <param-value>Basic realm="DMS Webdav Server"</param-value> </init-param> <init-param> <param-name>resource-config</param-name> <param-value>/WEB-INF/config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> {code} You can find the [^config.xml] as attachment. On Server B the JcrRemotingServlet is configured via following code. {code:java} @WebListener public class JcrWebListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent sce) { try { Repository repository = ... // Some code that starts the Repository Dynamic sr = sce.getServletContext().addServlet("JcrRemotingServlet", new JcrRemotingServlet(repository)); sr.setInitParameter("csrf-protection", "disabled"); sr.setInitParameter("resource-path-prefix", "/jcr/server"); sr.setInitParameter("concurrency-level", "100"); sr.setInitParameter("protectedhandlers-config", ""); sr.addMapping("/jcr/server/*"); sr.setLoadOnStartup(1); log.info("Das Repository wurde via HTTP [" + RuntimeConfigProvider.getServerURL() + "/jcr/server/" + "] gebunden."); } catch (Throwable e) { log.error(e); } } }{code} In the trace you can see the difference in the lock tokens as described. You must correlate the two log files based on the Timestamp. was (Author: c_koell): I have now implemented a WebFilter on both servers.. now we have a full trace of all http requests. On Server Server-A is configured a SimpleWebDavServlet. You can see the request/response from MSOffice-Word in the SimpleWebDavServlet.txt File The Remote Repository URL to Server-B looks like [http://localhost:9080/jcr/server.] On Server-B is configured a JcrRemotingServlet. You can also see the request/response in JcrRemotingServlet.txt File. Regarding configuration ... On Server-A the SimpleWebDavServlet is configured like following {code:java} <servlet> <description>The webdav servlet that connects HTTP request to the repository.</description> <servlet-name>WebdavServlet</servlet-name> <servlet-class>org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet</servlet-class> <init-param> <param-name>resource-path-prefix</param-name> <param-value>/repository</param-value> </init-param> <init-param> <param-name>authenticate-header</param-name> <param-value>Basic realm="DMS Webdav Server"</param-value> </init-param> <init-param> <param-name>resource-config</param-name> <param-value>/WEB-INF/config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> {code} You can find the config.xml as attachment. On Server B the JcrRemotingServlet is configured via following code. {code:java} @WebListener public class JcrWebListener implements ServletContextListener { @Override public void contextInitialized(ServletContextEvent sce) { try { Repository repository = ... // Some code that starts the Repository Dynamic sr = sce.getServletContext().addServlet("JcrRemotingServlet", new JcrRemotingServlet(repository)); sr.setInitParameter("csrf-protection", "disabled"); sr.setInitParameter("resource-path-prefix", "/jcr/server"); sr.setInitParameter("concurrency-level", "100"); sr.setInitParameter("protectedhandlers-config", ""); sr.addMapping("/jcr/server/*"); sr.setLoadOnStartup(1); log.info("Das Repository wurde via HTTP [" + RuntimeConfigProvider.getServerURL() + "/jcr/server/" + "] gebunden."); } catch (Throwable e) { log.error(e); } } }{code} In the trace you can see the difference in the lock tokens as described. You must correlate the two log files based on the Timestamp. > 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 > > > 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)