[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948344#comment-16948344
]
Julian Reschke commented on JCR-4458:
-
trunk: (2.19.5) [r1866280|http://svn.apache.org/r1866280]
2.18: [r1868234|http://svn.apache.org/r1868234]
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20, 2.19.5, 2.18.4
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927364#comment-16927364
]
Woonsan Ko commented on JCR-4458:
-
That makes sense to me.
Cheers,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.5
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926603#comment-16926603
]
Julian Reschke commented on JCR-4458:
-
FWIW, this changes the API, so in general we won't backport this to anything
but the latest stable branch (right now: 2.18). Is this acceptable?
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.5
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920884#comment-16920884
]
Julian Reschke commented on JCR-4458:
-
trunk: [r1866280|http://svn.apache.org/r1866280]
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.5
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919641#comment-16919641
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
I've updated the PR: https://github.com/apache/jackrabbit/pull/85, which
excludes changes in {{o.a.j.jcr2dav.RepositoryStubImpl}}.
I also created another ticket for the improvements of
{{o.a.j.jcr2dav.RepositoryStubImpl}}: JCR-4475
Cheers,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919621#comment-16919621
]
Julian Reschke commented on JCR-4458:
-
Thanks a lot.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919617#comment-16919617
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
Sure. It will be easy because I already submitted a patch only for
RepositoryStubImpl separately in JCR-4460 :
https://issues.apache.org/jira/secure/attachment/12975997/12975997_servlet_path_prefix.patch
I'll remove the changes of RepositoryStubImpl in the PR and notify you.
Thanks,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919582#comment-16919582
]
Julian Reschke commented on JCR-4458:
-
Hi [~woon_san] - could you move the changes to RepositoryStubImpl into a
seaparate ticket, and modify them slightly so that by default (no system
properties set), it tests exactly what was tested before?
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918656#comment-16918656
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
Yes, the changes fix the test case #4 in my last comment in JCR-4460: "With
custom context path". And the other changes in RepositoryStubImpl are
improvements to allow servlet path configurations as well.
And the reason why I ruled out the option of "changing/extending APIs in a way
that would avoid the thread local" is that I thought another approach I took in
https://github.com/apache/jackrabbit/pull/84 is hard to understand in
maintenance perspective and is by itself kind of indirect inference of context
path anyway. So, I thought it seems better to directly access and use the
request to determine the context path and easier to maintain..
Regards,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918621#comment-16918621
]
Julian Reschke commented on JCR-4458:
-
[~woon_san] - so the changes in
{{jackrabbit-jcr2dav/src/test/java/org/apache/jackrabbit/jcr2dav/RepositoryStubImpl.java}}
allow us to testa setup that we did not test before, and which will fail
without the other changes, right?
In that case I'd like to split that into a separate issue, and get it into the
code base right now.
WRT the actual change: I understand you ruled out changing/extending APIs in a
way that would avoid the thread local?
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918588#comment-16918588
]
Julian Reschke commented on JCR-4458:
-
in svn patch format: [^JCR-4458.diff] - tests pass for me
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911192#comment-16911192
]
Woonsan Ko commented on JCR-4458:
-
Hi [~julian.resc...@gmx.de] ,
No objection. :-) Please go ahead.
Best, Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911082#comment-16911082
]
Julian Reschke commented on JCR-4458:
-
[~woon_san] - I'll have a look, but it might take a few days. Any objections to
do a release of Jackrabbit trunk first?
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895685#comment-16895685
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
I've submitted a new PR: https://github.com/apache/jackrabbit/pull/85
This PR solves the problem case described above with jackrabbit-boot, and it
also makes all the integrationTesting scenarios* passed. The PR includes the
servlet_path_prefix.patch in JCR-4460.
Basically, in the same way how
{{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
boolean)}} normalizes the _input_ href value by removing the contextPath prefix
if found when creating a {{DavResourceLocator}}, the PR ensures every Report or
Resource handling classes to normalize the _input_ href value from the input
element when a {{DavResourceLocator}} needs to be created.
As Report handlers do not have an access to {{WebdavRequest}}, I ended up
introducing {{WebdavRequestContext}} and {{WebdavRequestContextHolder}}, which
are set and removed in {{AbstractWebdavServlet#service()}}, in order to get the
contextPath.
Please review the PR.
Thanks,
Woonsan
-
\* {{mvn clean install -PintegrationTesting}}, {{mvn clean install
-PintegrationTesting -DWebDAVServletPrefix=}}, and {{mvn clean install
-PintegrationTesting -DWebDAVServletContext="/foo"}}
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894062#comment-16894062
]
Woonsan Ko commented on JCR-4458:
-
I thought it would be straightforward by prepending the contextPath to the
given resource path prefix in the servlet with my patch for JCR-4460.
However, it seems more complex.
For example, some classes are removing the contextPath before resolving
locations, and some are concatenating the href prefix (including the
contextPath) and the path prefix (starting with contextPath again) when making
child node paths, and so on. There seems to have been some inconsistencies...
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892272#comment-16892272
]
Woonsan Ko commented on JCR-4458:
-
I've closed my PR because there seems to be an easier solution as explained in
JCR-4460.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890690#comment-16890690
]
Julian Reschke commented on JCR-4458:
-
I'd like first to understand why with JCR-4460 tests seems to pass once the
init param is set - so this certainly looks as "works as designed" to me
(although I'm not happy with the design).
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890599#comment-16890599
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
Could you please review my PR?
- https://github.com/apache/jackrabbit/pull/84
I think {{JcrPrivilegeReport}} needs to convert the input href to any of these
anyway:
# an absolute URL (e.g, {{http://localhost:8080/cms/server/default/jcr:root}}),
# a context relative path (e.g, {{/server/default/jcr:root}}),
# or just a JCR resource path (e.g, {{/default/jcr:root}}).
The third option seems best to me, and it seems to fix the problem case.
Regards,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889384#comment-16889384
]
Julian Reschke commented on JCR-4458:
-
Ah. See the comments in JCR-4460.
I believe there's a workaround (setting the init parameter to the context path)
- maybe you can try that in jackrabbit-boot.
(That said, this should work without extra config)
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889237#comment-16889237
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
After pulling the latest from trunk branch, I tried to reproduce it with the
regular integration tests with `{{mvn clean install -PintegrationTesting
-DWebDAVServletContext="/foobar/"}}`, but the build was successful.
Did I miss something?
Regards, Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887108#comment-16887108
]
Julian Reschke commented on JCR-4458:
-
[~woon_san] - see JCR-4460; I *think* I can now reproduce this type of problem
with the regular integration tests...
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886235#comment-16886235
]
angela commented on JCR-4458:
-
[~reschke], unfortunately not...
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886143#comment-16886143
]
Julian Reschke commented on JCR-4458:
-
It's not a big issue right now, thanks to the Windows Linux subsystem.
Understandimg the Jackrabbit code here is a bit harder...
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886130#comment-16886130
]
Woonsan Ko commented on JCR-4458:
-
Thanks, [~reschke]! I'll make jcr-shell work on Windows and let you know soon.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886126#comment-16886126
]
Julian Reschke commented on JCR-4458:
-
I can repro this as described above. That said, jcr-shell doesn't seem to work
properly under Windows (tty issue???).
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878542#comment-16878542
]
Woonsan Ko commented on JCR-4458:
-
Indeed. Seems like the same issue! :-)
Thanks a lot for your attention! I couldn’t figure out an easy solution
yesterday as JcrPrivilegeReport doesn’t have a direct access to servletContext.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878322#comment-16878322
]
Julian Reschke commented on JCR-4458:
-
Is this the same issue as JCR-3763?
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878198#comment-16878198
]
Woonsan Ko commented on JCR-4458:
-
If [1] is executed without contextPath ({{export
SERVER_SERVLET_CONTEXT_PATH=}}), and [2] is executed without contextPath as
well ({{--server="http://localhost:8080/server"}}), then "hello" node is
successfully imported without problem.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878190#comment-16878190
]
Woonsan Ko commented on JCR-4458:
-
If you want, you can reproduce the problem easily with the two tools [1,2] to
reproduce the problem.
h2. A problem case
- Start Jackrabbit server with a servlet context path ("/cms") using [1]:
{noformat}
$ export SERVER_SERVLET_CONTEXT_PATH=/cms
$ java \
> -Drepository.home=target/jackrabbit-repository \
> -Drepository.config=conf/simple-repository.xml \
> -Dloader.path=lib/ \
> -jar target/jackrabbit-boot-0.0.1-SNAPSHOT.jar
...
{noformat}
- Start JCR Shell [2] as a JCR/WebDAV client, list nodes in the root and try to
import an XML:
{noformat}
$ java -jar target/jcrshell-2.0.4-SNAPSHOT.jar \
>.--server="http://localhost:8080/cms/server; \
>.--user="admin:admin"
...
exit or quit leaves program.
help lists commands.
jcr-shell:> ls
done.
---
NameType
---
jcr:system rep:system
rep:policy rep:ACL
---
Command completed in 981 msecs.
admin:/> nodeimport hello.xml
UnsupportedRepositoryOperationException while executing nodeimport: Missing
implementation
admin:/>
{noformat}
- It fails with an {{UnsupportedRepositoryOperationException}}. The server [1]
prints the following stack traces:
{noformat}
{noformat}
2019-07-03 17:59:52.794 ERROR 9604 --- [nio-8080-exec-1]
o.a.c.c.C.[.[.[.[jcrRemotingServlet] : Servlet.service() for servlet
[jcrRemotingServlet] in context with path [/cms] threw exception
java.lang.IllegalArgumentException: Unexpected format of resource path:
/cms/server/default/jcr:root (workspace: /cms)
at
org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(DavLocatorFactoryImpl.java:65)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.getRepositoryPath(AbstractLocatorFactory.java:366)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.addResponses(JcrPrivilegeReport.java:130)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.init(JcrPrivilegeReport.java:114)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.version.report.ReportType.createReport(ReportType.java:72)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.AbstractResource.getReport(AbstractResource.java:513)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.WorkspaceResourceImpl.getReport(WorkspaceResourceImpl.java:88)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doReport(AbstractWebdavServlet.java:1117)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:416)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:305)
~[jackrabbit-webdav-2.18.2.jar!/:na]
...
{noformat}
-
[1] Jackrabbit-boot, https://github.com/woonsan/jackrabbit-boot
(A simple, minimalistic Jackrabbit 2 standalone application example using
Spring-boot like Jackrabbit Standalone.)
[2] https://bloomreach-forge.github.io/jcr-shell/
(An open source shell project to access remote JCR using JCR over WebDAV
protocol.)
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> 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:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new
