Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.18.2
-
None
Description
If org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet is configured in a non-root web application, the contextPath of which is "/cms" for example with the servletPath, "/server", then javax.jcr.Session#importXML(...) fails from a JCR client based on JCR/WebDAV. In other words, #importXML(...) fails from a JCR Session using a repository which can be created like the following for JCR over WebDAV:
String repositoryAddress = "http://localhost:8080/cms/server"; Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory(); Map<String, String> params = new HashMap<String, String>(); params.put(JcrUtils.REPOSITORY_URI, repositoryAddress); Repository repository = factory.getRepository(params); // ...
It seems like that Session#importXML(...) call invokes an AclResource Webdav request first on the specific resource path, but org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource, ReportInfo) does not remove the contextPath, "/cms" for example, when determining the resoucrePath.
Unlike the JcrPrivilegeReport, org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String, boolean) seems to remove the contextPath properly.