[
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)
