[jira] [Created] (JCR-4491) Upgrade Commons VFS to 2.5

2019-10-18 Thread Woonsan Ko (Jira)
Woonsan Ko created JCR-4491:
---

 Summary: Upgrade Commons VFS to 2.5
 Key: JCR-4491
 URL: https://issues.apache.org/jira/browse/JCR-4491
 Project: Jackrabbit Content Repository
  Issue Type: Task
Reporter: Woonsan Ko
Assignee: Woonsan Ko


Since we upgraded HttpComponents to 4.x, the VFSDataStore with WebDAV backend 
has been broken because the underlying HttpComponents conflicts with the old 
HttpClient 3.x used in VFS 2.4.x or earlier.
This issue is fixed in VFS-686, which can be possibly shipped in Commons VFS 
2.5.0.
So, once Commons VFS 2.5.0 is released, upgrade the dependency and check 
VFSDataStore with WebDAV backend working fine.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: [VOTE] Release Apache Jackrabbit Oak 1.6.18

2019-10-09 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.6.18

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T04:39:06+09:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS: -Xmx1024m

Regards,

Woonsan

On Wed, Oct 9, 2019 at 11:59 PM Nitin Gupta  wrote:
>
> A candidate for the Jackrabbit Oak 1.6.18 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.6.18/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.6.18/
>
> The SHA1 checksum of the archive is
> 52d432b74f97e8d7bfe34ff7f86ea4b9019773da.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.6.18
> 52d432b74f97e8d7bfe34ff7f86ea4b9019773da
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.6.18.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.6.18
> [ ] -1 Do not release this package because...
>
> -Nitin


Re: [VOTE] Release Apache Jackrabbit 2.19.5

2019-10-07 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.19.5

all checks okay where:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T04:39:06+09:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Thank you very much!

Woonsan

On Mon, Oct 7, 2019 at 1:45 PM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.19.5 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.19.5/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.19.5/
>
> The SHA1 checksum of the archive is
> 608301e6149f31da191419b45268e4de0639c097.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.19.5 608301e6149f31da191419b45268e4de0639c097
>
> Please vote on releasing this package as Apache Jackrabbit 2.19.5.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.19.5
>  [ ] -1 Do not release this package because...
>
>
> Best regards, Julian


Re: [VOTE] Release Apache Jackrabbit Oak 1.10.5

2019-09-13 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.10.5

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T04:39:06+09:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Fri, Sep 13, 2019 at 3:35 PM Nitin Gupta  wrote:
>
> A candidate for the Jackrabbit Oak 1.10.5 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.5/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.5/
>
> The SHA1 checksum of the archive is
> ac15e00db1b9e5c725a34f4abddcc9e03cb89b31.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.10.5
> ac15e00db1b9e5c725a34f4abddcc9e03cb89b31
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.10.5.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.10.5
> [ ] -1 Do not release this package because...
>
> -Nitin


Re: [VOTE] Release Apache Jackrabbit Oak 1.8.17

2019-09-13 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.8.17

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T04:39:06+09:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Thu, Sep 12, 2019 at 6:39 PM Nitin Gupta  wrote:
>
> A candidate for the Jackrabbit Oak 1.8.17 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.17/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.17/
>
> The SHA1 checksum of the archive is
> c2479868929f87a316d4ffb24b9d4ebf13f4f0be.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.8.17
> c2479868929f87a316d4ffb24b9d4ebf13f4f0be
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.17.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.17
> [ ] -1 Do not release this package because...
>
> -Nitin


[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-09-11 Thread Woonsan Ko (Jira)


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


Re: [VOTE] Release Apache Jackrabbit 2.14.8

2019-09-10 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.14.8

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T04:39:06+09:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Thank you!

Woonsan

On Mon, Sep 9, 2019 at 10:15 PM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.14.8 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.14.8/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.14.8/
>
> The SHA1 checksum of the archive is
> 1d4d6ba45c33e8a3b60314245a6250b60ee51883.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.14.8 1d4d6ba45c33e8a3b60314245a6250b60ee51883
>
> Please vote on releasing this package as Apache Jackrabbit 2.14.8.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.14.8
>  [ ] -1 Do not release this package because...


Re: [VOTE] Release Apache Jackrabbit 2.16.5

2019-09-03 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.16.5

All checks ok where:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T04:39:06+09:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Thank you!

Woonsan

On Mon, Sep 2, 2019 at 5:25 PM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.16.5 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.16.5/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.16.5/
>
> The SHA1 checksum of the archive is
> 531a0ff61c82b152bf864c68f5cef66b071b9038.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.16.5 531a0ff61c82b152bf864c68f5cef66b071b9038
>
> Please vote on releasing this package as Apache Jackrabbit 2.16.5.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.16.5
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


[jira] [Commented] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-31 Thread Woonsan Ko (Jira)


[ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920143#comment-16920143
 ] 

Woonsan Ko commented on JCR-4475:
-

Hi [~reschke],

I see your point. It makes sense to keep the empty path as is. I've uploaded a 
new patch with the empty servlet path by default to keep the same behavior:  
[^servlet_path_prefix2.patch] 

Thanks,

Woonsan

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>    Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch, servlet_path_prefix2.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-31 Thread Woonsan Ko (Jira)


 [ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4475:

Attachment: servlet_path_prefix2.patch

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>    Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch, servlet_path_prefix2.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Comment Edited] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-31 Thread Woonsan Ko (Jira)


[ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920143#comment-16920143
 ] 

Woonsan Ko edited comment on JCR-4475 at 8/31/19 2:53 PM:
--

Hi [~reschke],

I see your point. It makes sense to keep the empty servlet path as is. I've 
uploaded a new patch with the empty servlet path by default to keep the same 
behavior:  [^servlet_path_prefix2.patch] 

Thanks,

Woonsan


was (Author: woon_san):
Hi [~reschke],

I see your point. It makes sense to keep the empty path as is. I've uploaded a 
new patch with the empty servlet path by default to keep the same behavior:  
[^servlet_path_prefix2.patch] 

Thanks,

Woonsan

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>    Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch, servlet_path_prefix2.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Comment Edited] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


[ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919715#comment-16919715
 ] 

Woonsan Ko edited comment on JCR-4475 at 8/30/19 4:47 PM:
--

Yes, it changes the default servlet path mapping from "/*" to "/server/*", 
while giving an option to set it to empty one (the test case #2 above).
I thought the change would be better because that's how it is packaged and 
configured by default even in Jackrabbit-standalone. ;-)

BTW, we can possibly change the line like this to set the default servlet path 
to empty like before:
{code}
private static final String WEBDAV_SERVLET_PATH_PREFIX = 
System.getProperty("WebDAVServletPrefix", "");
{code}



was (Author: woon_san):
Yes, it changes the default servlet path mapping from "/*" to "/server/*", 
while giving an option to set it to empty one (the test case #2 above).
I thought the change would be better because that's how it is packaged and 
configured by default even in Jackrabbit-standalone. ;-)

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>      Issue Type: Improvement
>Affects Versions: 2.18.3
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


[ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919718#comment-16919718
 ] 

Woonsan Ko commented on JCR-4475:
-

Hi [~reschke],

I've just tested the test case #1 to #5 again, after apply the  
[^servlet_path_prefix.patch]  on top of the bug fix branch for JCR-4458. 
Everything seems working fine.

Regards,

Woonsan

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>    Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


[ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919715#comment-16919715
 ] 

Woonsan Ko commented on JCR-4475:
-

Yes, it changes the default servlet path mapping from "/*" to "/server/*", 
while giving an option to set it to empty one (the test case #2 above).
I thought the change would be better because that's how it is packaged and 
configured by default even in Jackrabbit-standalone. ;-)

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


 [ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4475:

Description: 
{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=1. Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=2. With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=3. With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=4. With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

{noformat:title=5. With custom context path and custom servlet path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
-DWebDAVServletPrefix="/jcrserver"
{noformat}

  was:
{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=1. Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=2. With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=3. With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=4. With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

{noformat:title=5. With custom context path and custom servlet path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
-DWebDAVServletPrefix="/jcrserver"
{noformat}


> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


 [ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4475:

Description: 
{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=1. Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=2. With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=3. With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=4. With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

{noformat:title=5. With custom context path and custom servlet path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
-DWebDAVServletPrefix="/jcrserver"
{noformat}

  was:
{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

{noformat:title=With custom context path and custom servlet path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
-DWebDAVServletPrefix="/jcrserver"
{noformat}


> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>Reporter: Woonsan Ko
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=1. Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=2. With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=3. With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=4. With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=5. With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


 [ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4475:

Description: 
{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

{noformat:title=With custom context path and custom servlet path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
-DWebDAVServletPrefix="/jcrserver"
{noformat}

  was:
{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}


> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
>     Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>Reporter: Woonsan Ko
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}
> {noformat:title=With custom context path and custom servlet path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo" 
> -DWebDAVServletPrefix="/jcrserver"
> {noformat}



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

2019-08-30 Thread Woonsan Ko (Jira)


[ 
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] [Updated] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)


 [ 
https://issues.apache.org/jira/browse/JCR-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4475:

Attachment: servlet_path_prefix.patch

> Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path 
> mapping
> -
>
> Key: JCR-4475
> URL: https://issues.apache.org/jira/browse/JCR-4475
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.18.3
>    Reporter: Woonsan Ko
>Priority: Major
> Fix For: 2.20
>
> Attachments: servlet_path_prefix.patch
>
>
> {{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
> custom context path like the following, but not with custom servlet path 
> mapping.
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}
> It would be nice if we can test with custom servlet path mapping as well, 
> instead of the hard-coded "/server" path only, like the following examples:
> {noformat:title=Default with /server prefix}
> $ mvn clean install -PintegrationTesting
> {noformat}
> {noformat:title=With empty servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
> {noformat}
> {noformat:title=With custom servlet path prefix}
> mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
> {noformat}
> {noformat:title=With custom context path}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Created] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping

2019-08-30 Thread Woonsan Ko (Jira)
Woonsan Ko created JCR-4475:
---

 Summary: Improve o.a.j.jcr2dav.RepositoryStubImpl to test with 
custom servlet path mapping
 Key: JCR-4475
 URL: https://issues.apache.org/jira/browse/JCR-4475
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
Affects Versions: 2.18.3
Reporter: Woonsan Ko
 Fix For: 2.20


{{org.apache.jackrabbit.jcr2dav.RepositoryStubImpl}} supports testing with 
custom context path like the following, but not with custom servlet path 
mapping.
{noformat}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
{noformat}

It would be nice if we can test with custom servlet path mapping as well, 
instead of the hard-coded "/server" path only, like the following examples:

{noformat:title=Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}

{noformat:title=With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}

{noformat:title=With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

{noformat:title=With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}



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

2019-08-30 Thread Woonsan Ko (Jira)


[ 
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

2019-08-29 Thread Woonsan Ko (Jira)


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


Re: [VOTE] Release Apache Jackrabbit 2.18.3

2019-08-27 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.18.3

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Thanks!

Regards,

Woonsan


On Tue, Aug 27, 2019 at 3:09 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.18.3 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.18.3/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.18.3/
>
> The SHA1 checksum of the archive is
> 0add5b6ae303396a2ce0792212b799394f2c300b.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.18.3 0add5b6ae303396a2ce0792212b799394f2c300b
>
> Please vote on releasing this package as Apache Jackrabbit 2.18.3.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.18.3
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


Re: [VOTE] Release Apache Jackrabbit Oak 1.8.16

2019-08-26 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.8.16

All checks ok where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Mon, Aug 26, 2019 at 4:53 AM Nitin Gupta  wrote:
>
> A candidate for the Jackrabbit Oak 1.8.16 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.16/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.16/
>
> The SHA1 checksum of the archive is
> 7f5fb1087721296704fbdc74284ac865843046eb.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.8.16
> 7f5fb1087721296704fbdc74284ac865843046eb
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.16.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.16
> [ ] -1 Do not release this package because...
>
>
> - Nitin


Re: [VOTE] Release Apache Jackrabbit 2.19.4

2019-08-21 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.19.4

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Wed, Aug 21, 2019 at 3:10 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.19.4 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.19.4/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.19.4/
>
> The SHA1 checksum of the archive is
> b2b589977e070af345351b6e6aed14f04de7aa0e.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.19.4 b2b589977e070af345351b6e6aed14f04de7aa0e
>
> Please vote on releasing this package as Apache Jackrabbit 2.19.4.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.19.4
>  [ ] -1 Do not release this package because...


[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-08-20 Thread Woonsan Ko (Jira)


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


Re: New Jackrabbit Committer: Mohit Kataria

2019-08-14 Thread Woonsan Ko
Welcome, Mohit!

Cheers,

Woonsan

On Wed, Aug 14, 2019 at 2:31 AM Tommaso Teofili
 wrote:
>
> Welcome to the team Mohit!
>
> Regards,
> Tommaso
>
> On Thu, 8 Aug 2019 at 08:33, Marcel Reutegger  wrote:
>>
>> Hi,
>>
>> Please welcome Mohit Kataria as a new committer and PMC member of
>> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
>> offer Mohit committership based on his contributions. I'm happy to
>> announce that he accepted the offer and that all the related
>> administrative work has now been taken care of.
>>
>> Welcome to the team, Mohit!
>>
>> Regards
>>  Marcel
>>


Re: New Jackrabbit Committer: Nitin Gupta

2019-08-14 Thread Woonsan Ko
Welcome, Nitin!

Cheers,

Woonsan

On Wed, Aug 14, 2019 at 2:30 AM Tommaso Teofili
 wrote:
>
> Welcome to the team Nitin!
>
> Regards,
> Tommaso
>
> On Thu, 8 Aug 2019 at 08:31, Marcel Reutegger  wrote:
>>
>> Hi,
>>
>> Please welcome Nitin Gupta as a new committer and PMC member of
>> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
>> offer Nitin committership based on his contributions. I'm happy to
>> announce that he accepted the offer and that all the related
>> administrative work has now been taken care of.
>>
>> Welcome to the team, Nitin!
>>
>> Regards
>>  Marcel
>>


Re: Are nested array node types valid in Jackrabbit JCR?

2019-08-13 Thread Woonsan Ko
On Tue, Aug 13, 2019 at 9:11 PM Grant McGovern
 wrote:
>
> Hello,
>
> Copying some bits from the corresponding Stackoverflow post I posted here: 
> https://stackoverflow.com/questions/57487251/are-nested-array-node-types-valid-in-jackrabbit-jcr
>  
> .
>
> Basically, I’m attempting to translate the following data model (business 
> requirement) into a JCR structure, and add it to an existing parent structure.
>
> {
> "someProperty": [
> [ "some-property-1", "some-property-2" ],
> [ "some-property-3", "some-property-4" ]
> ]
> }
> I’m new to the JCR world, but I’ve run into some issues with implementing 
> this ask. It seems like there’s no way to add a Node object that isn’t named, 
> which is what the nested subarrays would be in this case.
>
> There’s some more details on the SO link I posted above, but briefly 
> speaking, is it possible to store nested arrays in a JCR structure?

In my understanding, JCR 2.0 specification is not supposed to allow to
add an unnamed node. [1]
So, possible options in JCR structure probably include the following:
1. Each array in a multi-value property in a child node with either
same name siblings (e.g, "propnode", "propnode", ...) in Jackrabbit v2
or generated named (e.g, "propnode_1", "propnode_2", ...) nodes in
Oak.
2. Generated named properties without child nodes. e.g, @prop1 = [
"value1", "value2", ...], @prop2 = [ "value3", "value4", ...].
3. Single string property with specific formatted string such as json
format. @propinjson = "[ ... ]"

#1 looks more organized, but less convenient and less performant if
you want to search it - through JCR Query - by the nested node's
values.
#2 looks less organized, but probably more efficient in query.
#3 is problematic in queries with equals or like constraints.

Anyway, it will depend on your use case. Mostly on how you want to
query those, I guess.

Regards,

Woonsan

[1] 
https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Node.html#addNode(java.lang.String)

>
> Thanks,
> Grant


Re: [VOTE] Release Apache Jackrabbit Oak 1.10.4

2019-08-13 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.10.4

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T14:39:06-05:00)
[INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Mon, Aug 12, 2019 at 4:55 AM Nitin Gupta  wrote:
>
> A candidate for the Jackrabbit Oak 1.10.4 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.4/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.4/
>
> The SHA1 checksum of the archive is
> 7b6b435cbafe06253eca605eb7d639271a791a74.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.10.4
> 7b6b435cbafe06253eca605eb7d639271a791a74
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.10.4.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.10.4
> [ ] -1 Do not release this package because...


[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-29 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895685#comment-16895685
 ] 

Woonsan Ko edited comment on JCR-4458 at 7/30/19 1:08 AM:
--

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 class 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=}}, 
  {{mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"}}



was (Author: woon_san):
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=}}, 
  {{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] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-29 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895685#comment-16895685
 ] 

Woonsan Ko edited comment on JCR-4458 at 7/30/19 1:07 AM:
--

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=}}, 
  {{mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"}}



was (Author: woon_san):
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

2019-07-29 Thread Woonsan Ko (JIRA)


[ 
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] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-29 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878190#comment-16878190
 ] 

Woonsan Ko edited comment on JCR-4458 at 7/30/19 12:49 AM:
---

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}
$ cat hello.xml
http://www.jcp.org/jcr/sv/1.0;>
  
Hello, World!
  
  
2009-11-17T12:00:00.000Z
  


$ 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}
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.)


was (Author: woon_san):
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}
$ cat hello.xml
http://www.jcp.org/jcr/sv/1.0;>
  
Hello, World!
  
  
2009-11-17T12:00:00.000Z
  


$ java -jar target/jcrshell-2.0.4-SNAPSHOT.jar \
>.--server="http://localhost:8080/cms/server; \
>.--use

[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-26 Thread Woonsan Ko (JIRA)


[ 
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-4460) allow to run remoted conformance tests with a custom servlet context path

2019-07-26 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894059#comment-16894059
 ] 

Woonsan Ko commented on JCR-4460:
-

Hi [~reschke],

I've attached a new patch only for this ticket:  [^servlet_path_prefix.patch] .

Now, any of the following succeeds:
{noformat:title=Default with /server prefix}
$ mvn clean install -PintegrationTesting
{noformat}
{noformat:title=With empty servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix=""
{noformat}
{noformat:title=With custom servlet path prefix}
mvn clean install -PintegrationTesting -DWebDAVServletPrefix="/jcrserver"
{noformat}

However, as expected (which is the goal with this ticket), test with a custom 
context path fails:
{noformat:title=With custom context path}
mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"
{noformat}

Regards,

Woonsan


> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: servlet_path_prefix.patch, use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

2019-07-26 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4460:

Attachment: servlet_path_prefix.patch

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: servlet_path_prefix.patch, use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

2019-07-26 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893973#comment-16893973
 ] 

Woonsan Ko commented on JCR-4460:
-

Now I realize that the {{INIT_PARAM_RESOURCE_PATH_PREFIX}} init parameter is 
really necessary because the servlet cannot infer the servlet path during 
initialization.
In order to keep supporting the scenarios where the servlet is configured at a 
specific servlet path (e.g, {{/server/*}} in a {{/foo}} servlet context, the 
init parameter must be set to {{/server}} in the servlet configuration. The 
servlet should prepend the contextPath, {{/foo}}, during initialization.
I'll try to provide a new patch.

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

2019-07-26 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893921#comment-16893921
 ] 

Woonsan Ko commented on JCR-4460:
-

Hi [~reschke],

I will try, but shouldn't it concatenate the contextPath ("/foo") and 
servletPath ("/server")? Otherwise, it would work only when the servlet is 
mapped to "/*", no?

Woonsan

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


Re: New Jackrabbit Committer: Dominik Süß

2019-07-25 Thread Woonsan Ko
Welcome, Dominik!

Cheers,

Woonsan

On Thu, Jul 25, 2019 at 9:54 AM Marcel Reutegger  wrote:
>
> Hi,
>
> Please welcome Dominik Süß as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Dominik committership based on his contributions. I'm happy to
> announce that he accepted the offer and that all the related
> administrative work has now been taken care of.
>
> Welcome to the team, Dominik!
>
> Regards
> Marcel


Re: New Jackrabbit Committer: Konrad Windszus

2019-07-25 Thread Woonsan Ko
Welcome, Konrad!

Cheers,

Woonsan

On Wed, Jul 24, 2019 at 10:11 AM Konrad Windszus  wrote:
>
> Hi everyone,
> thanks a lot for having invited me.
> Some words about myself: I have experience with AEM/CQ since 2005. I am now 
> working for Netcentric. I joined the Apache family in 2014 by becoming an 
> Apache Sling committer. Meanwhile I am part of the Apache Sling PMC.
>
> I am looking forward to contribute even more in the future to Jackrabbit/Oak.
> Particularly I am interested in improving Filevault and the related Maven 
> Plugin.
>
> Konrad
>
>
> > On 24. Jul 2019, at 15:37, Marcel Reutegger  wrote:
> >
> > Hi,
> >
> > Please welcome Konrad Windszus as a new committer and PMC member of
> > the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> > offer Konrad committership based on his contributions. I'm happy to
> > announce that he accepted the offer and that all the related
> > administrative work has now been taken care of.
> >
> > Welcome to the team, Konrad!
> >
> > Regards
> > Marcel
> >
>


[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path

2019-07-25 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892655#comment-16892655
 ] 

Woonsan Ko commented on JCR-4460:
-

One theoretical use case of the explicit path prefix init param is when the 
servlet doesn’t have a servlet path. For example, a filter uses a named 
dispatcher to the servlet.

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



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

2019-07-24 Thread Woonsan Ko (JIRA)


[ 
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-4460) allow to run remoted conformance tests with a custom servlet context path

2019-07-24 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892271#comment-16892271
 ] 

Woonsan Ko commented on JCR-4460:
-

Hi [~reschke],

Perhaps you already knew it, but here's my findings:
- The reason why it fails in my testing (JCR-4458) but it doesn't with the 
integrationTesting is because the former sets the 
{{INIT_PARAM_RESOURCE_PATH_PREFIX}} init parameter to a context relative path 
(e.g, {{/server}}) whereas the latter in {{RepositoryStubImpl}} sets it to a 
path including the context path (e.g, {{/app1/server}}).
- As a result, {{org.apache.jackrabbit.webdav.AbstractLocatorFactory}} 
instances have different values: one without the contextPath and the other with 
it for the {{pathPrefix}} member.
- So, 
{{org.apache.jackrabbit.webdav.AbstractLocatorFactory#createResourceLocator(String,
 String)}} is able to remove the contextPath when executing the 
integrationTesting.

I think that the init param configuration, {{INIT_PARAM_RESOURCE_PATH_PREFIX}}, 
should still be a context relative path without contextPath to avoid any 
deployment issues.
But I guess the servlet may prepend the contextPath for its {{pathPrefix}} 
member setting.

Regards,

Woonsan

> allow to run remoted conformance tests with a custom servlet context path
> -
>
> Key: JCR-4460
> URL: https://issues.apache.org/jira/browse/JCR-4460
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-jcr2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_16
> Fix For: 2.20, 2.19.4, 2.18.3
>
> Attachments: use-context-path.diff
>
>
> Add a system property that selects a servlet context path for testing.
> To run tests with non-root path:
> {noformat}
> mvn clean install -PintegrationTesting -DWebDAVServletContext="/foobar/"
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


Re: [VOTE] Release Apache Jackrabbit Oak 1.16.0

2019-07-24 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.16.0

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Wed, Jul 24, 2019 at 2:26 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit Oak 1.16.0 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.16.0/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.16.0/
>
> The SHA1 checksum of the archive is
> 33c9722c4fc8b5f836b64d217961962ab095b2a3.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
>  $ sh check-release.sh oak 1.16.0
> 33c9722c4fc8b5f836b64d217961962ab095b2a3
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.16.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit Oak 1.16.0
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-22 Thread Woonsan Ko (JIRA)


[ 
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

2019-07-19 Thread Woonsan Ko (JIRA)


[ 
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

2019-07-16 Thread Woonsan Ko (JIRA)


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


Re: [VOTE] Release Apache Jackrabbit Filevault Package Maven Plugin 1.0.4

2019-07-16 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Filevault Package
Maven Plugin 1.0.4

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Mon, Jul 15, 2019 at 10:51 PM Tobias Bocanegra  wrote:
>
> Hello,
>
> A candidate for the Jackrabbit Filevault Package Maven Plugin 1.0.4 release 
> is available at:
> https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.0.4/
>
> The release candidate is a zip archive of the sources in:
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault-package-maven-plugin/tags/filevault-package-maven-plugin-1.0.4/
>
> The SHA1 checksum of the archive is
> 6030e0de70ca59bfe31c40eeccd8eab38a981e77
>
> The command for running automated checks against this release candidate is:
> $ sh check-release.sh filevault-plugin 1.0.4 
> 6030e0de70ca59bfe31c40eeccd8eab38a981e77
>
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachejackrabbit-1450
>
> Please vote on releasing this package as Apache Jackrabbit Filevault Package 
> Maven Plugin 1.0.4.
> The vote is open for a minimum of 72 hours during business days and passes
> if a majority of at least three +1 Jackrabbit PMC votes are cast.
> The vote fails if not enough votes are cast after 1 week (5 business days).
>
> [ ] +1 Release this package as Apache Jackrabbit Filevault Package Maven 
> Plugin 1.0.4
> [ ] -1 Do not release this package because...
>
> Thanks,
> Regards, Toby


Re: [VOTE] Release Apache Jackrabbit Oak 1.8.15

2019-07-10 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.8.15

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Wed, Jul 10, 2019 at 6:16 AM Davide Giannella  wrote:
>
>
>
> A candidate for the Jackrabbit Oak 1.8.15 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.15/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.15/
>
> The SHA1 checksum of the archive is
> 0e3f17b263fc090ffc5d9bf14b75d4671d662f82.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.8.15
> 0e3f17b263fc090ffc5d9bf14b75d4671d662f82
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.15.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.15
> [ ] -1 Do not release this package because...
> D.


Re: [VOTE] Release Apache Jackrabbit Oak 1.10.3

2019-07-10 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.10.3

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Tue, Jul 9, 2019 at 7:17 AM Davide Giannella  wrote:
>
>
>
> A candidate for the Jackrabbit Oak 1.10.3 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.3/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.3/
>
> The SHA1 checksum of the archive is
> 0109dc1a21350bcaae18c29c575a7e8deef823aa.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.10.3
> 0109dc1a21350bcaae18c29c575a7e8deef823aa
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.10.3.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.10.3
> [ ] -1 Do not release this package because...
> D.


[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-04 Thread Woonsan Ko (JIRA)


[ 
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

2019-07-03 Thread Woonsan Ko (JIRA)


[ 
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] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-03 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878190#comment-16878190
 ] 

Woonsan Ko edited comment on JCR-4458 at 7/3/19 10:13 PM:
--

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}
$ cat hello.xml
http://www.jcp.org/jcr/sv/1.0;>
  
Hello, World!
  
  
2009-11-17T12:00:00.000Z
  


$ 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}
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.)


was (Author: woon_san):
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=

[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-03 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878190#comment-16878190
 ] 

Woonsan Ko edited comment on JCR-4458 at 7/3/19 10:12 PM:
--

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}
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.)


was (Author: woon_san):
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.
--

[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-03 Thread Woonsan Ko (JIRA)


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

[jira] [Updated] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-03 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4458:

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:

{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.

  was:
If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is 
configured as a servlet on servletPath, "/server", in a web application, the 
contextPath of which is "/cms" for example, then 
{{javax.jcr.Session#importXML(...)}} fails from a JCR client based on 
JCR/WebDAV. In other words, from a JCR Session from the repository like the 
following:

{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 property.


> 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] [Updated] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-03 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4458:

Description: 
If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is 
configured as a servlet on servletPath, "/server", in a web application, the 
contextPath of which is "/cms" for example, then 
{{javax.jcr.Session#importXML(...)}} fails from a JCR client based on 
JCR/WebDAV. In other words, from a JCR Session from the repository like the 
following:

{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 property.

  was:
If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is 
configured as a servlet on servletPath, "/server", in a web application, the 
contextPath of which is "/cms" for example, then 
{{javax.jcr.Session#importXML(...)}} fails from a JCR client based on 
JCR/WebDAV. In other words, from a JCR Session from the repository like the 
following:

{code}
String repositoryAddress = (args.length != 0) ? args[0] : 
"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 property.


> 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 as a servlet on servletPath, "/server", in a web application, the 
> contextPath of which is "/cms" for example, then 
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on 
> JCR/WebDAV. In other words, from a JCR Session from the repository like the 
> following:
> {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 property.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails

2019-07-03 Thread Woonsan Ko (JIRA)
Woonsan Ko created JCR-4458:
---

 Summary: 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


If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is 
configured as a servlet on servletPath, "/server", in a web application, the 
contextPath of which is "/cms" for example, then 
{{javax.jcr.Session#importXML(...)}} fails from a JCR client based on 
JCR/WebDAV. In other words, from a JCR Session from the repository like the 
following:

{code}
String repositoryAddress = (args.length != 0) ? args[0] : 
"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 property.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: [VOTE] Release Apache Jackrabbit Oak 1.8.14

2019-07-02 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.8.14

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Regards,

Woonsan

On Mon, Jul 1, 2019 at 8:17 AM Davide Giannella  wrote:
>
>
>
> A candidate for the Jackrabbit Oak 1.8.14 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.14/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.14/
>
> The SHA1 checksum of the archive is
> d66e467c647a58accb26e795dc2805daef6ec290.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.8.14
> d66e467c647a58accb26e795dc2805daef6ec290
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.14.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.14
> [ ] -1 Do not release this package because...
>
> D.


Re: Microsoft Exchange listener

2019-06-24 Thread Woonsan Ko
On Mon, Jun 24, 2019 at 7:20 AM zatrox  wrote:
>
> Hi all,
>
> I'm quite new to Jackrabbit world and have a newbie question.
>
> I need to listen an Exchange e-mail account and store these e-mails in
> Jackrabbit after performing some classifications (by a rule engine or
> machine learning algorithm) and take some actions such as calling a rest api
> etc with the classification result.
>
> For eg. if the customer is sending a complaint mail then call ticketing
> system's api for creating a ticket.
>
> Is there a bulit-in function or toolset for this scenario?

I think Apache Sling (https://sling.apache.org/) is the best built-in
toolset with Apache Jackrabbit OAK.
Also see these:
- https://sling.apache.org/documentation/getting-started.html
- 
https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html

Regards,

Woonsan

>
> Your help is greatly appreciated.
>
>
>
> --
> Sent from: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-Dev-f523400.html


Re: [VOTE] Release Apache Jackrabbit Oak 1.14.0

2019-06-05 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.14.0

...where...

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Wed, Jun 5, 2019 at 11:55 AM Davide Giannella  wrote:
>
> A candidate for the Jackrabbit Oak 1.14.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.14.0/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.14.0/
>
> The SHA1 checksum of the archive is
> 2fcaff6ddb40ec67b7d8b141809fc2a9192f5260.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.14.0
> 2fcaff6ddb40ec67b7d8b141809fc2a9192f5260
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.14.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.14.0
> [ ] -1 Do not release this package because...
> D.


Re: [VOTE] Release Apache Jackrabbit 2.14.7

2019-06-04 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.14.7

verified with:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Regards,

Woonsan

On Tue, Jun 4, 2019 at 5:22 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.14.7 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.14.7/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.14.7/
>
> The SHA1 checksum of the archive is
> fdb7351243a5efc92b4c6732c80ba8c79ac9a4b8.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.14.7 fdb7351243a5efc92b4c6732c80ba8c79ac9a4b8
>
> Please vote on releasing this package as Apache Jackrabbit 2.14.7.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.14.7
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


Re: Question related to Root node and their management in V1.5.0

2019-05-29 Thread Woonsan Ko
On Wed, May 29, 2019 at 3:27 AM Richa Kumari  wrote:
>
> Hi Dev Team
>
>
>
> We are using Jackrabbit for our content repository and the version 1.5.0 is 
> getting used.  The application was developed by 3rd party in early 2005-2007 
> . We  are trying to understand the process of saving the XML file and mapping 
> with our dataset. We understood that our key is the node or folder in the 
> repository however we are not able to locate the direct relationship in the 
> table rep_binval.binval_data and the our foreign key. We also noticed that 
> system does not update the information but its retrieve and delete them and 
> create the updated one as the new record. Our target area is to understand 
> how the rep_prop or rep_node store the foreign key relation to retrieve the 
> data.
>

The tables are internal details which you're not supposed to direct
access. You should always use JCR API [1,2] instead to access the JCR
hierarchical data.

Regards,

Woonsan

[1] http://jackrabbit.apache.org/jcr/jcr-api.html
[2] https://docs.adobe.com/docs/en/spec/jcr/1.0/index.html

>
>
> Hoping to reach you guys about and get any help to understand the node and 
> especially root node which stores in the baseFolder. We also noticed that 
> when system starts up, it has the rootUUID value in the cached folder (folder 
> location \repository\meta)  but others are not created or stored inside any 
> other folder.
>
>
>
> Hope to see your reply soon.
>
>
>
> Thank you.
>
>
>
> Best Regards,
>
> Richa
>
>
>
> Please consider the environment before printing this message. CTIS, Inc. 
> CONFIDENTIAL COMMUNICATION This email and any files transmitted with it are 
> confidential and are intended solely for use by the individual or entity to 
> whom addressed. If you have received this email in error, do not forward, 
> print, or copy, this email. Instead, please immediately notify us by 
> telephone at (301) 948-3033 or by reply email to the sender. Please delete 
> this email and its attachments from your system and do not retain any copies. 
> Thank you.


Re: [VOTE] Release Apache Jackrabbit 2.18.2

2019-05-25 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.18.2

verified in:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Thanks,

Woonsan

On Thu, May 23, 2019 at 2:37 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.18.2 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.18.2/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.18.2/
>
> The SHA1 checksum of the archive is
> 1059c4495a47f86d19cab5c3e4d2a38e9d0aede9.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.18.2 1059c4495a47f86d19cab5c3e4d2a38e9d0aede9
>
> Please vote on releasing this package as Apache Jackrabbit 2.18.2.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.18.2
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


Re: [VOTE] Release Apache Jackrabbit Oak 1.8.13

2019-05-10 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.8.13

All checks ok:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Thu, May 9, 2019 at 10:31 AM Marcel Reutegger
 wrote:
>
> A candidate for the Jackrabbit Oak 1.8.13 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.13/
>
> The release candidate is a zip archive of the sources in:
>
> 
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.13/
>
> The SHA1 checksum of the archive is 451d68f0f3dd66cc59e6e273ce96541bd98c968c.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.8.13 451d68f0f3dd66cc59e6e273ce96541bd98c968c
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.13.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.13
> [ ] -1 Do not release this package because...
>
> Regards
>  Marcel
>


Re: [VOTE] Release Apache Jackrabbit 2.19.3

2019-05-07 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.19.3

All checks ok in my env:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Mon, May 6, 2019 at 10:56 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.19.3 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.19.3/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.19.3/
>
> The SHA1 checksum of the archive is
> 3fd2f9ab7939c5e67a7507685fb032646c91a7ba.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.19.3 3fd2f9ab7939c5e67a7507685fb032646c91a7ba
>
> Please vote on releasing this package as Apache Jackrabbit 2.19.3.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.19.3
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


Re: [VOTE] Release Apache Jackrabbit 2.16.4

2019-05-01 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.16.4

All check okay on my env:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Wed, May 1, 2019 at 10:51 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.16.4 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.16.4/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.16.4/
>
> The SHA1 checksum of the archive is
> 97a9e382643f76cdae2c8719dd96998eb0e4d9a3.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.16.4 97a9e382643f76cdae2c8719dd96998eb0e4d9a3
>
> Please vote on releasing this package as Apache Jackrabbit 2.16.4.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.16.4
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


Re: New PMC chair for Apache Jackrabbit: Marcel Reutegger

2019-04-23 Thread Woonsan Ko
Welcome, Marcel! Thank you for taking the role!
And, thank you so much, Michael, for serving the community for such a long time!

Cheers,

Woonsan

On Tue, Apr 23, 2019 at 6:23 AM Michael Dürig  wrote:
>
> Hi,
>
> After 7 years it is time for me to step down and pass the PMC chair role on
> to someone else. A big thank you to all my colleagues on the PMC for the
> good collaboration we had over the years.
>
> The PMC has elected Marcel Reutegger for the role of the next PMC chair and
> at their meeting last week the ASF board ratified the change.
>
> Please join me in welcoming Marcel in his new role!
>
> Michael
>
> PS, please consult [1] for details about the PMC chair role.
>
> [1] http://www.apache.org/foundation/how-it-works.html#pmc-chair


Re: New PMC chair for Apache Jackrabbit: Marcel Reutegger

2019-04-23 Thread Woonsan Ko
Welcome, Marcel! Thank you for taking the role!
And, thank you so much, Michael, for serving the community for such a long time!

Cheers,

Woonsan

On Tue, Apr 23, 2019 at 6:23 AM Michael Dürig  wrote:
>
> Hi,
>
> After 7 years it is time for me to step down and pass the PMC chair role on
> to someone else. A big thank you to all my colleagues on the PMC for the
> good collaboration we had over the years.
>
> The PMC has elected Marcel Reutegger for the role of the next PMC chair and
> at their meeting last week the ASF board ratified the change.
>
> Please join me in welcoming Marcel in his new role!
>
> Michael
>
> PS, please consult [1] for details about the PMC chair role.
>
> [1] http://www.apache.org/foundation/how-it-works.html#pmc-chair


[jira] [Closed] (JCR-4421) Release Jackrabbit 2.19.2

2019-04-12 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed JCR-4421.
---

> Release Jackrabbit 2.19.2
> -
>
> Key: JCR-4421
> URL: https://issues.apache.org/jira/browse/JCR-4421
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>    Reporter: Woonsan Ko
>        Assignee: Woonsan Ko
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (JCR-4421) Release Jackrabbit 2.19.2

2019-04-12 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko resolved JCR-4421.
-
Resolution: Fixed

> Release Jackrabbit 2.19.2
> -
>
> Key: JCR-4421
> URL: https://issues.apache.org/jira/browse/JCR-4421
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>    Reporter: Woonsan Ko
>        Assignee: Woonsan Ko
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: [VOTE] Release Apache Jackrabbit 2.18.1

2019-04-12 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.18.1

All checks OK.

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Fri, Apr 12, 2019 at 6:35 AM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit 2.18.1 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/2.18.1/
>
> The release candidate is a zip archive of the sources in:
>
>  https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.18.1/
>
> The SHA1 checksum of the archive is
> 8e4b1cb74212102ef2672a48fd45a65b2419c215.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit/
>  $ sh check-release.sh 2.18.1 8e4b1cb74212102ef2672a48fd45a65b2419c215
>
> Please vote on releasing this package as Apache Jackrabbit 2.18.1.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit 2.18.1
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


[ANNOUNCE] Apache Jackrabbit 2.19.2 released

2019-04-12 Thread Woonsan Ko
The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.19.2. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:



Release Notes -- Apache Jackrabbit -- Version 2.19.2

Introduction


This is Apache Jackrabbit(TM) 2.19.2, a fully compliant implementation of the
Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.19.2 is an unstable release cut directly from
Jackrabbit trunk, with a focus on new features and other
improvements. For production use we recommend the latest stable 2.18.x
release.

Changes in Jackrabbit 2.19.2


Bug

[JCR-4420] - Release Notes: term "SHA1" no longer allowed

Improvement

[JCR-4401] - Split jackrabbit-standalone to
jackrabbit-standalone-components and the rest

Task

[JCR-4415] - Update Jetty dependency to 9.2.26.v20180806
[JCR-4416] - Update slf4j dependency to 1.7.26
[JCR-4422] - Update httpclient/mime dependencies to 4.5.8

In addition to the above-mentioned changes, this release contains
all the changes included up to the Apache Jackrabbit 2.19.1 release.

For more detailed information about all the changes in this and other
Jackrabbit releases, please see the Jackrabbit issue tracker at

https://issues.apache.org/jira/browse/JCR

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.txt file for instructions on how to build this release.

The source archive is accompanied by an SHA512 checksum and a
PGP signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit
---

Apache Jackrabbit is a fully conforming implementation of the Content
Repository for Java Technology API (JCR). A content repository is a
hierarchical content store with support for structured and unstructured
content, full text search, versioning, transactions, observation, and
more.

For more information, visit http://jackrabbit.apache.org/

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

Trademarks
--

Apache Jackrabbit, Jackrabbit, Apache, the Apache feather logo, and the Apache
Jackrabbit project logo are trademarks of The Apache Software Foundation.


[ANNOUNCE] Apache Jackrabbit 2.19.2 released

2019-04-12 Thread Woonsan Ko
The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit 2.19.2. The release is available for download at:

 http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:



Release Notes -- Apache Jackrabbit -- Version 2.19.2

Introduction


This is Apache Jackrabbit(TM) 2.19.2, a fully compliant implementation of the
Content Repository for Java(TM) Technology API, version 2.0 (JCR 2.0) as
specified in the Java Specification Request 283 (JSR 283).

Apache Jackrabbit 2.19.2 is an unstable release cut directly from
Jackrabbit trunk, with a focus on new features and other
improvements. For production use we recommend the latest stable 2.18.x
release.

Changes in Jackrabbit 2.19.2


Bug

[JCR-4420] - Release Notes: term "SHA1" no longer allowed

Improvement

[JCR-4401] - Split jackrabbit-standalone to
jackrabbit-standalone-components and the rest

Task

[JCR-4415] - Update Jetty dependency to 9.2.26.v20180806
[JCR-4416] - Update slf4j dependency to 1.7.26
[JCR-4422] - Update httpclient/mime dependencies to 4.5.8

In addition to the above-mentioned changes, this release contains
all the changes included up to the Apache Jackrabbit 2.19.1 release.

For more detailed information about all the changes in this and other
Jackrabbit releases, please see the Jackrabbit issue tracker at

https://issues.apache.org/jira/browse/JCR

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.txt file for instructions on how to build this release.

The source archive is accompanied by an SHA512 checksum and a
PGP signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit
---

Apache Jackrabbit is a fully conforming implementation of the Content
Repository for Java Technology API (JCR). A content repository is a
hierarchical content store with support for structured and unstructured
content, full text search, versioning, transactions, observation, and
more.

For more information, visit http://jackrabbit.apache.org/

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

Trademarks
--

Apache Jackrabbit, Jackrabbit, Apache, the Apache feather logo, and the Apache
Jackrabbit project logo are trademarks of The Apache Software Foundation.


[RESULT] [VOTE] Release Apache Jackrabbit 2.19.2

2019-04-11 Thread Woonsan Ko
Hi there,

The vote passes as follows:

+1 Davide Giannella 
+1 Julian Reschke 
+1 Marcel Reutegger 
+1 Woonsan Ko 

Thanks for voting. I'll push the release out.

Best regards, Woonsan


On Fri, Apr 5, 2019 at 7:14 PM Woonsan Ko  wrote:
>
> A candidate for the Jackrabbit 2.19.2 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/2.19.2/
>
> The release candidate is a zip archive of the sources in:
>
> https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.19.2/
>
> The SHA1 checksum of the archive is f0e8fae7aa523d81f96a720e99a6bcb2c88f9d39.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of 
> https://dist.apache.org/repos/dist/dev/jackrabbit/
> $ sh check-release.sh 2.19.2 f0e8fae7aa523d81f96a720e99a6bcb2c88f9d39
>
> Please vote on releasing this package as Apache Jackrabbit 2.19.2.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit 2.19.2
> [ ] -1 Do not release this package because...
>
> Best regards, Woonsan


Re: [VOTE] Release Apache Jackrabbit Oak 1.12.0

2019-04-09 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.12.0

All checks okay:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Tue, Apr 9, 2019 at 10:52 AM Davide Giannella  wrote:
>
> A candidate for the Jackrabbit Oak 1.12.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.12.0/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.12.0/
>
> The SHA1 checksum of the archive is
> fb5f678a4720128d15ff9d8c62a4ab92dc7d6cc8.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.12.0
> fb5f678a4720128d15ff9d8c62a4ab92dc7d6cc8
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.12.0.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.12.0
> [ ] -1 Do not release this package because...
> D.


Re: [VOTE] Release Apache Jackrabbit Oak 1.6.17

2019-04-08 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.6.17

All checks OK:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:

Regards,

Woonsan

On Mon, Apr 8, 2019 at 10:56 AM Davide Giannella  wrote:
>
>
>
> A candidate for the Jackrabbit Oak 1.6.17 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.6.17/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.6.17/
>
> The SHA1 checksum of the archive is
> 1bf92037b7ea69196462f41ea0528e4cdd835ca8.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.6.17
> 1bf92037b7ea69196462f41ea0528e4cdd835ca8
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.6.17.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.6.17
> [ ] -1 Do not release this package because...
>
> D.


Re: [VOTE] Release Apache Jackrabbit 2.19.2

2019-04-08 Thread Woonsan Ko
On Mon, Apr 8, 2019 at 3:52 AM Marcel Reutegger  wrote:
>
> Hi,
>
> On 06.04.19, 01:14, "Woonsan Ko"  wrote:
> > Please vote on releasing this package as Apache Jackrabbit 2.19.2. The
> > vote is open for the next 72 hours and passes if a majority of at least
> > three +1 Jackrabbit PMC votes are cast.
>
> +1 Release this package as Apache Jackrabbit 2.19.2
>
> All checks OK.
>
> Please note, you should only close the resolved issues for the release
> after a successful vote. The Jackrabbit project in JIRA uses a workflow
> that doesn't allow re-opening closed issues.

That was my bad. Sorry about that.
I surmised that wrongly when I read the step 15 of the part I. I
should have read the part II carefully beforehand.
And I realized that I couldn't reopen afterward; now I see the intention.
Thanks for the pointers!

Regards,

Woonsan

>
> See also http://jackrabbit.apache.org/jcr/creating-releases.html
>
> Regards
>  Marcel
>


Re: [VOTE] Release Apache Jackrabbit 2.19.2

2019-04-05 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit 2.19.2

All look good:

[INFO] 
[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.4", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Regards,

Woonsan


On Fri, Apr 5, 2019 at 7:14 PM Woonsan Ko  wrote:
>
> A candidate for the Jackrabbit 2.19.2 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/2.19.2/
>
> The release candidate is a zip archive of the sources in:
>
> https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.19.2/
>
> The SHA1 checksum of the archive is f0e8fae7aa523d81f96a720e99a6bcb2c88f9d39.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of 
> https://dist.apache.org/repos/dist/dev/jackrabbit/
> $ sh check-release.sh 2.19.2 f0e8fae7aa523d81f96a720e99a6bcb2c88f9d39
>
> Please vote on releasing this package as Apache Jackrabbit 2.19.2.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit 2.19.2
> [ ] -1 Do not release this package because...
>
> Best regards, Woonsan


[jira] [Closed] (JCR-4422) Update httpclient/mime dependencies to 4.5.8

2019-04-05 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed JCR-4422.
---

> Update httpclient/mime dependencies to 4.5.8
> 
>
> Key: JCR-4422
> URL: https://issues.apache.org/jira/browse/JCR-4422
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: jackrabbit-spi2dav, jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (JCR-4415) Update Jetty dependency to 9.2.26.v20180806

2019-04-05 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed JCR-4415.
---

> Update Jetty dependency to 9.2.26.v20180806
> ---
>
> Key: JCR-4415
> URL: https://issues.apache.org/jira/browse/JCR-4415
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest

2019-04-05 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed JCR-4401.
---

> Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
> 
>
> Key: JCR-4401
> URL: https://issues.apache.org/jira/browse/JCR-4401
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-standalone
>Affects Versions: 2.19.0
>    Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Major
> Fix For: 2.20, 2.19.2
>
>
> I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5 to the 
> latest of 2.x for the WebDAV vfs provider. The fix will allow to use WebDAV 
> DataStore backend again. (Since JR upgraded httpclient to v4.x, WebDAV 
> backend has been broken.)
> One problem is that the test case for WebDAV vfs provider counts on 
> jackrabbit-standalone dependency--to start an extended JR Main for 
> testing--which has been unavailable in maven repos for long time. It's 
> understandable not to deploy the module as it's too big.
> At the same time, it would be awkward if VFS should contain all the necessary 
> JR dependencies as jackrabbit-standalone does.
> I think it would be nice if we split the module, by moving all the Java 
> classes and resources with most dependencies, except of jackrabbit-webapp, to 
> a new maven module (e.g, "jackrabbit-standalone-components") and having 
> dependency on this new module and webapp module in jackrabbit-standalone 
> bundle module. This will let VFS keep the JR dependencies simple and easy.
> \[1\] https://issues.apache.org/jira/browse/VFS-686



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (JCR-4420) Release Notes: term "SHA1" no longer allowed

2019-04-05 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed JCR-4420.
---

> Release Notes: term "SHA1" no longer allowed
> 
>
> Key: JCR-4420
> URL: https://issues.apache.org/jira/browse/JCR-4420
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Davide Giannella
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.12.10, 2.16.4, 2.14.7, 2.10.10, 2.18.1, 2.19.2, 2.8.11
>
>
> In the release notes we mention the word {{SHA1}} which is no longer allowed 
> and will be bounced back by announce@.
> Remove it from RELEASE-NOTES.txt of all active branches.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (JCR-4416) Update slf4j dependency to 1.7.26

2019-04-05 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed JCR-4416.
---

> Update slf4j dependency to 1.7.26
> -
>
> Key: JCR-4416
> URL: https://issues.apache.org/jira/browse/JCR-4416
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[VOTE] Release Apache Jackrabbit 2.19.2

2019-04-05 Thread Woonsan Ko
A candidate for the Jackrabbit 2.19.2 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/2.19.2/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.19.2/

The SHA1 checksum of the archive is f0e8fae7aa523d81f96a720e99a6bcb2c88f9d39.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

# run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit/
$ sh check-release.sh 2.19.2 f0e8fae7aa523d81f96a720e99a6bcb2c88f9d39

Please vote on releasing this package as Apache Jackrabbit 2.19.2.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit 2.19.2
[ ] -1 Do not release this package because...

Best regards, Woonsan


Re: Jackrabbit 2.19.2 Release Plan

2019-04-04 Thread Woonsan Ko
On Thu, Apr 4, 2019 at 2:30 PM Julian Reschke  wrote:
>
> On 03.04.2019 22:01, Woonsan Ko wrote:
> > Hi,
> >
> > I'd like to cut Jackrabbit 2.19.2 this weekend or early next week.
> >
> > The list of open issues scheduled for 2.19.2 is empty:
> >
> > https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.19.2%20AND%20project%20%3D%20JCR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
> >
> > The candidate release notes are here:
> >
> > https://svn.apache.org/repos/asf/jackrabbit/trunk/RELEASE-NOTES.txt
> >
> > If there are any objections please let me know.
> >
> > Best regards,
> >
> > Woonsan
>
> I just opened JCR-4422 (httpclient update) and resolved it. I also
> updated the candidate release notes accordingly...

Cool! Thank you so much, Julian!

Woonsan

>
> Best regards, Julian
>


Jackrabbit 2.19.2 Release Plan

2019-04-03 Thread Woonsan Ko
Hi,

I'd like to cut Jackrabbit 2.19.2 this weekend or early next week.

The list of open issues scheduled for 2.19.2 is empty:

https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.19.2%20AND%20project%20%3D%20JCR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

The candidate release notes are here:

https://svn.apache.org/repos/asf/jackrabbit/trunk/RELEASE-NOTES.txt

If there are any objections please let me know.

Best regards,

Woonsan


[jira] [Created] (JCR-4421) Release Jackrabbit 2.19.2

2019-04-03 Thread Woonsan Ko (JIRA)
Woonsan Ko created JCR-4421:
---

 Summary: Release Jackrabbit 2.19.2
 Key: JCR-4421
 URL: https://issues.apache.org/jira/browse/JCR-4421
 Project: Jackrabbit Content Repository
  Issue Type: Task
Reporter: Woonsan Ko
Assignee: Woonsan Ko






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Jackrabbit 2.19.2 release?

2019-04-03 Thread Woonsan Ko
Hi,

I'd like to volunteer for cutting Jackrabbit 2.19.2 unless anyone else
already plans to do.
The list of open issues scheduled for 2.19.2 is:
- https://issues.apache.org/jira/projects/JCR/versions/12344895

I will try to follow [1], probably starting with registering my key in
KEYS and preparing a RELEASE-NOTES.txt, and ask you if I get any
questions in the process. I hope to start the process this week.

Please let me know if you have any concerns or remarks.

Kind regards,

Woonsan

[1] http://jackrabbit.apache.org/jcr/creating-releases.html


Re: [VOTE] Release Apache Jackrabbit Oak 1.10.2

2019-03-18 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.10.2

RELEASE-NOTES.txt looks good and all checks are okay:

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T21:39:06+02:00)
[INFO] OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Regards,

Woonsan

On Mon, Mar 18, 2019 at 3:08 PM Julian Reschke  wrote:
>
> A candidate for the Jackrabbit Oak 1.10.2 release is available at:
>
>  https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.2/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.2/
>
> The SHA1 checksum of the archive is
> 37f6e1b80bbe6edf21722d10afc3fa294b1889c4.
>
> A staged Maven repository is available for review at:
>
>  https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
>  # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
>  $ sh check-release.sh oak 1.10.2
> 37f6e1b80bbe6edf21722d10afc3fa294b1889c4
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.10.2.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
>  [ ] +1 Release this package as Apache Jackrabbit Oak 1.10.2
>  [ ] -1 Do not release this package because...
>
> Best regards, Julian


Re: [VOTE] Release Apache Jackrabbit Filevault 3.2.8

2019-03-18 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Filevault 3.2.8

RELEASE-NOTES.txt looks good and all checks okay:

[INFO] 
[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

Thanks,

Woonsan



On Sun, Mar 17, 2019 at 9:33 PM Tobias Bocanegra  wrote:
>
> A candidate for the Jackrabbit Filevault 3.2.8 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/filevault/3.2.8/
>
> The release candidate is a zip archive of the sources in:
>
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/tags/jackrabbit-filevault-3.2.8/
>
> The SHA1 checksum of the archive is 7720d7882f5fb51758449a6bd7f3900fc8025e9b.
>
> The command for running automated checks against this release candidate is:
> $ sh check-release.sh filevault 3.2.8 7720d7882f5fb51758449a6bd7f3900fc8025e9b
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachejackrabbit-1409/
>
> Please vote on releasing this package as Apache Jackrabbit Filevault 3.2.8.
> The vote is open for a minimum of 72 hours during business days and passes
> if a majority of at least three +1 Jackrabbit PMC votes are cast.
> The vote fails if not enough votes are cast after 1 week (5 business days).
>
> [ ] +1 Release this package as Apache Jackrabbit Filevault 3.2.8
> [ ] -1 Do not release this package because...
>
>
> Thanks.
> Regards, Toby


[jira] [Resolved] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest

2019-03-17 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko resolved JCR-4401.
-
Resolution: Fixed

> Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
> 
>
> Key: JCR-4401
> URL: https://issues.apache.org/jira/browse/JCR-4401
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-standalone
>Affects Versions: 2.19.0
>    Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Major
> Fix For: 2.20, 2.19.2
>
>
> I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5 to the 
> latest of 2.x for the WebDAV vfs provider. The fix will allow to use WebDAV 
> DataStore backend again. (Since JR upgraded httpclient to v4.x, WebDAV 
> backend has been broken.)
> One problem is that the test case for WebDAV vfs provider counts on 
> jackrabbit-standalone dependency--to start an extended JR Main for 
> testing--which has been unavailable in maven repos for long time. It's 
> understandable not to deploy the module as it's too big.
> At the same time, it would be awkward if VFS should contain all the necessary 
> JR dependencies as jackrabbit-standalone does.
> I think it would be nice if we split the module, by moving all the Java 
> classes and resources with most dependencies, except of jackrabbit-webapp, to 
> a new maven module (e.g, "jackrabbit-standalone-components") and having 
> dependency on this new module and webapp module in jackrabbit-standalone 
> bundle module. This will let VFS keep the JR dependencies simple and easy.
> \[1\] https://issues.apache.org/jira/browse/VFS-686



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest

2019-03-17 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4401:

Fix Version/s: 2.20

> Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
> 
>
> Key: JCR-4401
> URL: https://issues.apache.org/jira/browse/JCR-4401
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-standalone
>Affects Versions: 2.19.0
>    Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Major
> Fix For: 2.20, 2.19.2
>
>
> I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5 to the 
> latest of 2.x for the WebDAV vfs provider. The fix will allow to use WebDAV 
> DataStore backend again. (Since JR upgraded httpclient to v4.x, WebDAV 
> backend has been broken.)
> One problem is that the test case for WebDAV vfs provider counts on 
> jackrabbit-standalone dependency--to start an extended JR Main for 
> testing--which has been unavailable in maven repos for long time. It's 
> understandable not to deploy the module as it's too big.
> At the same time, it would be awkward if VFS should contain all the necessary 
> JR dependencies as jackrabbit-standalone does.
> I think it would be nice if we split the module, by moving all the Java 
> classes and resources with most dependencies, except of jackrabbit-webapp, to 
> a new maven module (e.g, "jackrabbit-standalone-components") and having 
> dependency on this new module and webapp module in jackrabbit-standalone 
> bundle module. This will let VFS keep the JR dependencies simple and easy.
> \[1\] https://issues.apache.org/jira/browse/VFS-686



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest

2019-03-17 Thread Woonsan Ko (JIRA)


 [ 
https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko updated JCR-4401:

Fix Version/s: 2.19.2

> Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
> 
>
> Key: JCR-4401
> URL: https://issues.apache.org/jira/browse/JCR-4401
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-standalone
>Affects Versions: 2.19.0
>    Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Major
> Fix For: 2.19.2
>
>
> I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5 to the 
> latest of 2.x for the WebDAV vfs provider. The fix will allow to use WebDAV 
> DataStore backend again. (Since JR upgraded httpclient to v4.x, WebDAV 
> backend has been broken.)
> One problem is that the test case for WebDAV vfs provider counts on 
> jackrabbit-standalone dependency--to start an extended JR Main for 
> testing--which has been unavailable in maven repos for long time. It's 
> understandable not to deploy the module as it's too big.
> At the same time, it would be awkward if VFS should contain all the necessary 
> JR dependencies as jackrabbit-standalone does.
> I think it would be nice if we split the module, by moving all the Java 
> classes and resources with most dependencies, except of jackrabbit-webapp, to 
> a new maven module (e.g, "jackrabbit-standalone-components") and having 
> dependency on this new module and webapp module in jackrabbit-standalone 
> bundle module. This will let VFS keep the JR dependencies simple and easy.
> \[1\] https://issues.apache.org/jira/browse/VFS-686



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest

2019-03-17 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794603#comment-16794603
 ] 

Woonsan Ko edited comment on JCR-4401 at 3/17/19 10:20 PM:
---

Merged PR: https://github.com/apache/jackrabbit/pull/82

-

Added a new submodule, jackrabbit-standalone-components, which contains most of 
the dependencies and classes and resource, while jackrabbit-standalone includes 
all of those transitively through jackrabbit-standalone-components.
I've used this, jackrabbit-standalone-components in the new webdav4 provider of 
Commons VFS. Everything seems working fine now. I made a pull request there for 
review purpose for now: https://github.com/apache/commons-vfs/pull/52

By the way, I've made two changes in the standalone Main class for the cases 
where unit tests starts a Jackrabbit standalone {{Main}}:

- Make {{#run}} public, so unit tests can easily instantiate and start it.
- Add #shutdown as public, so unit tests can make a graceful shutdown before 
JVM shutdown hook takes the place.


was (Author: woon_san):
Merged PR: https://github.com/apache/jackrabbit/pull/82

-

Added a new submodule, jackrabbit-standalone-components, which contains most of 
the dependencies and classes and resource, while jackrabbit-standalone includes 
all of those transitively through jackrabbit-standalone-components.
I've used this, jackrabbit-standalone-components in the new webdav4 provider of 
Commons VFS. Everything seems working fine now. I made a pull request there for 
review purpose for now: apache/commons-vfs#52

By the way, I've made two changes in the standalone Main class for the cases 
where unit tests starts a Jackrabbit standalone {{Main}}:

- Make {{#run}} public, so unit tests can easily instantiate and start it.
- Add #shutdown as public, so unit tests can make a graceful shutdown before 
JVM shutdown hook takes the place.

> Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
> 
>
> Key: JCR-4401
> URL: https://issues.apache.org/jira/browse/JCR-4401
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-standalone
>Affects Versions: 2.19.0
>    Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Major
>
> I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5 to the 
> latest of 2.x for the WebDAV vfs provider. The fix will allow to use WebDAV 
> DataStore backend again. (Since JR upgraded httpclient to v4.x, WebDAV 
> backend has been broken.)
> One problem is that the test case for WebDAV vfs provider counts on 
> jackrabbit-standalone dependency--to start an extended JR Main for 
> testing--which has been unavailable in maven repos for long time. It's 
> understandable not to deploy the module as it's too big.
> At the same time, it would be awkward if VFS should contain all the necessary 
> JR dependencies as jackrabbit-standalone does.
> I think it would be nice if we split the module, by moving all the Java 
> classes and resources with most dependencies, except of jackrabbit-webapp, to 
> a new maven module (e.g, "jackrabbit-standalone-components") and having 
> dependency on this new module and webapp module in jackrabbit-standalone 
> bundle module. This will let VFS keep the JR dependencies simple and easy.
> \[1\] https://issues.apache.org/jira/browse/VFS-686



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest

2019-03-17 Thread Woonsan Ko (JIRA)


[ 
https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16794603#comment-16794603
 ] 

Woonsan Ko commented on JCR-4401:
-

Merged PR: https://github.com/apache/jackrabbit/pull/82

-

Added a new submodule, jackrabbit-standalone-components, which contains most of 
the dependencies and classes and resource, while jackrabbit-standalone includes 
all of those transitively through jackrabbit-standalone-components.
I've used this, jackrabbit-standalone-components in the new webdav4 provider of 
Commons VFS. Everything seems working fine now. I made a pull request there for 
review purpose for now: apache/commons-vfs#52

By the way, I've made two changes in the standalone Main class for the cases 
where unit tests starts a Jackrabbit standalone {{Main}}:

- Make {{#run}} public, so unit tests can easily instantiate and start it.
- Add #shutdown as public, so unit tests can make a graceful shutdown before 
JVM shutdown hook takes the place.

> Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
> 
>
> Key: JCR-4401
> URL: https://issues.apache.org/jira/browse/JCR-4401
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-standalone
>Affects Versions: 2.19.0
>    Reporter: Woonsan Ko
>Assignee: Woonsan Ko
>Priority: Major
>
> I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5 to the 
> latest of 2.x for the WebDAV vfs provider. The fix will allow to use WebDAV 
> DataStore backend again. (Since JR upgraded httpclient to v4.x, WebDAV 
> backend has been broken.)
> One problem is that the test case for WebDAV vfs provider counts on 
> jackrabbit-standalone dependency--to start an extended JR Main for 
> testing--which has been unavailable in maven repos for long time. It's 
> understandable not to deploy the module as it's too big.
> At the same time, it would be awkward if VFS should contain all the necessary 
> JR dependencies as jackrabbit-standalone does.
> I think it would be nice if we split the module, by moving all the Java 
> classes and resources with most dependencies, except of jackrabbit-webapp, to 
> a new maven module (e.g, "jackrabbit-standalone-components") and having 
> dependency on this new module and webapp module in jackrabbit-standalone 
> bundle module. This will let VFS keep the JR dependencies simple and easy.
> \[1\] https://issues.apache.org/jira/browse/VFS-686



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: [VOTE] Release Apache Jackrabbit Oak 1.2.31

2019-03-11 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.2.31

[INFO] 
[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

RELEASE-NOTES.txt looks good as well.

Regards,

Woonsan

On Mon, Mar 11, 2019 at 11:01 AM Davide Giannella  wrote:
>
>
>
> A candidate for the Jackrabbit Oak 1.2.31 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.2.31/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.2.31/
>
> The SHA1 checksum of the archive is
> c9614802583543657069fe3fbec550ddc6b65dd0.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.2.31
> c9614802583543657069fe3fbec550ddc6b65dd0
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.2.31.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.2.31
> [ ] -1 Do not release this package because...
>
> D.


Re: [VOTE] Release Apache Jackrabbit Oak 1.8.12

2019-03-11 Thread Woonsan Ko
[X] +1 Release this package as Apache Jackrabbit Oak 1.8.12

[INFO] 
[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
[INFO] OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
[INFO] Java version: 1.8.0_144, vendor: Oracle Corporation
[INFO] MAVEN_OPTS:
[INFO] 
[INFO] ALL CHECKS OK

RELEASE-NOTES.txt looks good, too.

Regards,

Woonsan


On Mon, Mar 11, 2019 at 8:14 AM Davide Giannella  wrote:
>
>
>
> A candidate for the Jackrabbit Oak 1.8.12 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.8.12/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.8.12/
>
> The SHA1 checksum of the archive is
> 5cb421d0b160898b25df94ab1a10c4e391119c03.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.8.12
> 5cb421d0b160898b25df94ab1a10c4e391119c03
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.8.12.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.8.12
> [ ] -1 Do not release this package because...
>
> D.


Re: Splitting jackrabbit-standalone?

2019-03-06 Thread Woonsan Ko
Hi,

I managed to create a pull request for JCR-4401 [1] -- separating
jackrabbit-standalone-components from jackrabbit-standalone, mainly
for VFS-686 [2]:
With a local build from my feature/JCR-4401 branch, everything seems
working fine: new webdav4 VFS provider [3]. Jackrabbit also seems
successful in unit tests.
If there's no issue, then I'll merge it to trunk next week.

Thanks,

Woonsan

[1] https://github.com/apache/jackrabbit/pull/82
[2] https://issues.apache.org/jira/browse/VFS-686
[3] https://github.com/apache/commons-vfs/pull/52

On Tue, Jan 8, 2019 at 12:19 AM Woonsan Ko  wrote:
>
> On Thu, Jan 3, 2019 at 11:59 PM Julian Reschke  wrote:
> >
> > On 2019-01-03 14:30, Woonsan Ko wrote:
> > > Hi,
> > >
> > > I'd like to help fix VFS-686 [1] by upgrading JR dependency from 1.6.5
> > > to 2.18.x for the WebDAV vfs provider. The fix will allow to use
> > > WebDAV DataStore backend again. (Since JR upgraded httpclient to v4.x,
> > > WebDAV backend has been broken.)
> > >
> > > One problem is that the test case for WebDAV vfs provider counts on
> > > jackrabbit-standalone dependency--to start an extended JR Main for
> > > testing--which has been unavailable in maven repos for long time. It's
> > > understandable not to deploy the module as it's too big.
> > > At the same time, it would be awkward if VFS should contain all the
> > > necessary JR dependencies as jackrabbit-standalone does.
> > >
> > > I think it would be nice if we split the module, by moving all the
> > > Java classes and resources with most dependencies, except of
> > > jackrabbit-webapp, to a new maven module (e.g,
> > > "jackrabbit-standalone-components") and having dependency on this new
> > > module and webapp module in jackrabbit-standalone bundle module. This
> > > will let VFS keep the JR dependencies simple and easy.
> > >
> > > How does it sound?
> > > ...
> >
> >
> > Sounds good to me.
>
> Thanks Julian!
> I've created a ticket: https://issues.apache.org/jira/browse/JCR-4401
> My plan is, (a) to create a pull request (for review purpose from
> myself and others if possible), (b) to create another pull request for
> VFS-686 to test and validate with my feature branch, (c) merge (a) if
> everything is okay.
>
> By the way, I don't seem to be able to assign JCR-4401 to myself.
> Could someone allow me to do that?
>
> Kind regards,
>
> Woonsan
>
> >
> > Best regards, Julian


  1   2   3   >