[jira] [Commented] (JCR-5025) standalone: deprecate remote repository support (RMI and JNDI)
[
https://issues.apache.org/jira/browse/JCR-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816283#comment-17816283
]
Woonsan Ko commented on JCR-5025:
-
Hi [~reschke],
Nice catch! Indeed, {{ConnectToJNDIServer}} depends only on the RMI repository.
Not sure of the original intent, but it's logical to deprecate it too as it's
just a JNDI wrapper.
Thanks!
Woonsan
> standalone: deprecate remote repository support (RMI and JNDI)
> --
>
> Key: JCR-5025
> URL: https://issues.apache.org/jira/browse/JCR-5025
> Project: Jackrabbit Content Repository
> Issue Type: Task
> Components: jackrabbit-standalone, jackrabbit-standalone-components
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jackrabbit_2_20
> Fix For: 2.22, 2.21.24
>
>
> Interestingly, that would also deprecate (and later remove) *JNDI* support,
> which weirdly uses RMI classes.
> [~woonsan] - would that be a problem?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4957) jackrabbit-standalone: 2.21.18 breaks binary compatibility
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750039#comment-17750039
]
Woonsan Ko commented on JCR-4957:
-
Thanks a lot for the quick fix!
I created a new ticket, VFS-841, in order to just copy the Main class instead
of inheriting.
Cheers,
Woonsan
> jackrabbit-standalone: 2.21.18 breaks binary compatibility
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-standalone-components
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jackrabbit_2_20
> Fix For: 2.22, 2.21.19
>
> Attachments: jcr-4957.patch
>
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4957) Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
[
https://issues.apache.org/jira/browse/JCR-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746785#comment-17746785
]
Woonsan Ko commented on JCR-4957:
-
Hi [~reschke],
I recall somethings on why/how commons-vfs2 relies on the standalone-components
(not standalone itself).
As described in JCR-4401 (and discussed [1]), Jackrabbit has split the old
standalone module into two: standalone (a demo) and standalone-components (a
library). To help commons-vfs2 be able to verify its VFS2 over WebDAV, we moved
some public classes originally in the demo project to the library project, at
least for commons-vfs2 as of JCR-4401.
I'm not sure if it is feasible to bring it back easily, but it would be great
to see commons-VFS2 being verified with JR webdav server.
Woonsan
[1] https://lists.apache.org/thread/87rdszdzx4nqc7x0o9x4y10p338doc1p
> Jackrabbit 2.21.18 breaks binary compatiblity with 2.21.17
> --
>
> Key: JCR-4957
> URL: https://issues.apache.org/jira/browse/JCR-4957
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.21.18
>Reporter: Gary D. Gregory
>Priority: Major
>
> We see this break in Apache Commons VFS when trying to update from 2.21.17 to
> 2.21.18:
> {quote}[INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,27]
> incompatible types: java.lang.String[] cannot be converted to
> org.apache.commons.cli.CommandLine
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[231,18]
> cannot find symbol
> symbol: constructor (java.lang.String[])
> [ERROR]
> /C:/Users/ggregory/git/a/commons-vfs/commons-vfs2-jackrabbit2/src/test/java/org/apache/commons/vfs2/provider/webdav4/test/Webdav4ProviderTestCase.java:[235,15]
> method run in class org.apache.jackrabbit.standalone.Main cannot be applied
> to given types;
> required: java.io.File,java.io.File,java.io.File
> found: no arguments
> reason: actual and formal argument lists differ in length
> [INFO] 3 errors
> {quote}
> Breaking BC in a non-major release should not be allowed IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737382#comment-17737382 ] Woonsan Ko commented on JCR-4926: - Thanks! Will come up with a new PR for docs. > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Major > Fix For: 2.22, 2.21.17 > > > In the region where I work, I see CUBRID database [1][2] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID > [2] https://www.cubrid.org/downloads -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko reassigned JCR-4926: --- Assignee: Woonsan Ko (was: Julian Reschke) > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Major > Fix For: 2.22, 2.21.17 > > > In the region where I work, I see CUBRID database [1][2] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID > [2] https://www.cubrid.org/downloads -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736956#comment-17736956 ] Woonsan Ko commented on JCR-4926: - Documentation should be good enough! The wiki seems to have been archived, so I can perhaps do the following: - In the FAQ page (https://jackrabbit.apache.org/jcr/frequently-asked-questions.html), add a new item, "How do I support a new DBMS?" under the "Using Jackrabbit" section, with a link to a separate document which explains how to add a new database support in general, giving an example for CUBRID. Does this sound okay? Thanks, Woonsan > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Julian Reschke >Priority: Major > Fix For: 2.22, 2.21.17 > > > In the region where I work, I see CUBRID database [1][2] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID > [2] https://www.cubrid.org/downloads -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714475#comment-17714475 ] Woonsan Ko edited comment on JCR-4926 at 4/20/23 8:06 AM: -- PR is ready for review: https://github.com/apache/jackrabbit/pull/131 I've tested it working fine in a simple CMS application configured like the following: ``` http://jackrabbit.apache.org/dtd/repository-2.0.dtd;> ``` And JDBC setting example: - driver: cubrid.jdbc.driver.CUBRIDDriver - url: 'jdbc:CUBRID:localhost:33000:repodb:public::?charSet=utf-8' - username: '' - password: '' was (Author: woonsan): PR is ready for review: https://github.com/apache/jackrabbit/pull/131 I've tested it working fine in a simple CMS application configured like the following: ``` http://jackrabbit.apache.org/dtd/repository-2.0.dtd;> ``` > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Julian Reschke >Priority: Major > Fix For: 2.22, 2.21.17 > > > In the region where I work, I see CUBRID database [1][2] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID > [2] https://www.cubrid.org/downloads -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated JCR-4926: Description: In the region where I work, I see CUBRID database [1][2] being adopted, especially in the public sector. It seems like CUBRID is regarded as one of the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. So I'd like to support the database in Jackrabbit 2 first and then maintain and port it to OAK later. (OSGi is not quite popular yet here.) Even if Cubrid is not as popular as other OSS projects, it might be helpful to support here. [1] https://en.wikipedia.org/wiki/CUBRID [2] https://www.cubrid.org/downloads was: In the region where I work, I see CUBRID database [1] being adopted, especially in the public sector. It seems like CUBRID is regarded as one of the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. So I'd like to support the database in Jackrabbit 2 first and then maintain and port it to OAK later. (OSGi is not quite popular yet here.) Even if Cubrid is not as popular as other OSS projects, it might be helpful to support here. [1] https://en.wikipedia.org/wiki/CUBRID > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Julian Reschke >Priority: Major > Fix For: 2.21.17 > > > In the region where I work, I see CUBRID database [1][2] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID > [2] https://www.cubrid.org/downloads -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko reassigned JCR-4926: --- Assignee: Julian Reschke (was: Woonsan Ko) Hi [~reschke], Would you mind reviewing my PR when you have some time? (Not so urgent..) Thanks in advance, Woonsan > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Julian Reschke >Priority: Major > Fix For: 2.21.17 > > > In the region where I work, I see CUBRID database [1] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4926) Support CUBRID database in Jackrabbit 2
[ https://issues.apache.org/jira/browse/JCR-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714475#comment-17714475 ] Woonsan Ko commented on JCR-4926: - PR is ready for review: https://github.com/apache/jackrabbit/pull/131 I've tested it working fine in a simple CMS application configured like the following: ``` http://jackrabbit.apache.org/dtd/repository-2.0.dtd;> ``` > Support CUBRID database in Jackrabbit 2 > --- > > Key: JCR-4926 > URL: https://issues.apache.org/jira/browse/JCR-4926 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering, jackrabbit-core, jackrabbit-data >Reporter: Woonsan Ko >Assignee: Woonsan Ko >Priority: Major > Fix For: 2.21.17 > > > In the region where I work, I see CUBRID database [1] being adopted, > especially in the public sector. It seems like CUBRID is regarded as one of > the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. > So I'd like to support the database in Jackrabbit 2 first and then maintain > and port it to OAK later. (OSGi is not quite popular yet here.) > Even if Cubrid is not as popular as other OSS projects, it might be helpful > to support here. > [1] https://en.wikipedia.org/wiki/CUBRID -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-4926) Support CUBRID database in Jackrabbit 2
Woonsan Ko created JCR-4926: --- Summary: Support CUBRID database in Jackrabbit 2 Key: JCR-4926 URL: https://issues.apache.org/jira/browse/JCR-4926 Project: Jackrabbit Content Repository Issue Type: Improvement Components: clustering, jackrabbit-core, jackrabbit-data Reporter: Woonsan Ko Assignee: Woonsan Ko Fix For: 2.21.17 In the region where I work, I see CUBRID database [1] being adopted, especially in the public sector. It seems like CUBRID is regarded as one of the OSS DBMS alternatives (with PostgreSQL and MariaDB) here. So I'd like to support the database in Jackrabbit 2 first and then maintain and port it to OAK later. (OSGi is not quite popular yet here.) Even if Cubrid is not as popular as other OSS projects, it might be helpful to support here. [1] https://en.wikipedia.org/wiki/CUBRID -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCR-4766) JcrRemotingServlet should write application/json content for JSON response
[
https://issues.apache.org/jira/browse/JCR-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495495#comment-17495495
]
Woonsan Ko commented on JCR-4766:
-
PR ready for review: https://github.com/apache/jackrabbit/pull/96
> JcrRemotingServlet should write application/json content for JSON response
> --
>
> Key: JCR-4766
> URL: https://issues.apache.org/jira/browse/JCR-4766
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.21.10
>Reporter: Woonsan Ko
>Priority: Minor
>
> When retrieving a JCR node using JSON binding like the following by appending
> '.json' to the path, the content-type of the response should have been
> {{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
> {{GET http://localhost:8080/server/default/jcr:root/hello.json}}
> Reproduction:
> - Create a node (e.g, hello) like the following (excerpt from [1]):
> {code}
> $ curl --request MKCOL --data @- --user name:pass \
>http://localhost:8080/server/default/jcr:root/hello/ < http://www.jcp.org/jcr/sv/1.0;>
>
> Hello, World!
>
>
> 2022-01-15T12:00:00.000Z
>
>
> END
> {code}
> - Retrieve the node by JSON binding:
> {code}
> $ curl -i --user admin:admin
> http://localhost:8080/server/default/jcr:root/hello.json
> {code}
> - The {{Content-Type}} response header should be "application/json" or one of
> its compatibles.
> But the actual value is "text/plain;charset=utf-8".
> [1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JCR-4766) JcrRemotingServlet should write application/json content for JSON response
[
https://issues.apache.org/jira/browse/JCR-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4766:
Description:
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
Reproduction:
- Create a node (e.g, hello) like the following (excerpt from [1]):
{code}
$ curl --request MKCOL --data @- --user name:pass \
http://localhost:8080/server/default/jcr:root/hello/
Hello, World!
2022-01-15T12:00:00.000Z
END
{code}
- Retrieve the node by JSON binding:
{code}
$ curl -i --user admin:admin
http://localhost:8080/server/default/jcr:root/hello.json
{code}
- The {{Content-Type}} response header should be "application/json" or one of
its compatibles.
But the actual value is "text/plain;charset=utf-8".
[1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
was:
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
Reproduction:
- Create a node (e.g, hello) like the following (excerpt from [1]):
{code}
$ curl --request MKCOL --data @- --user name:pass \
http://localhost:8080/server/default/jcr:root/hello/
Hello, World!
2022-01-15T12:00:00.000Z
END
{code}
- Retrieve the node by JSON binding:
{code}
$ curl -i --user admin:admin
http://localhost:8080/server/default/jcr:root/hello.json
{code}
- The {{Content-Type}} response header should be "application/json" or one of
its compatibles.
[1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
> JcrRemotingServlet should write application/json content for JSON response
> --
>
> Key: JCR-4766
> URL: https://issues.apache.org/jira/browse/JCR-4766
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.21.10
>Reporter: Woonsan Ko
>Priority: Minor
>
> When retrieving a JCR node using JSON binding like the following by appending
> '.json' to the path, the content-type of the response should have been
> {{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
> {{GET http://localhost:8080/server/default/jcr:root/hello.json}}
> Reproduction:
> - Create a node (e.g, hello) like the following (excerpt from [1]):
> {code}
> $ curl --request MKCOL --data @- --user name:pass \
>http://localhost:8080/server/default/jcr:root/hello/ < http://www.jcp.org/jcr/sv/1.0;>
>
> Hello, World!
>
>
> 2022-01-15T12:00:00.000Z
>
>
> END
> {code}
> - Retrieve the node by JSON binding:
> {code}
> $ curl -i --user admin:admin
> http://localhost:8080/server/default/jcr:root/hello.json
> {code}
> - The {{Content-Type}} response header should be "application/json" or one of
> its compatibles.
> But the actual value is "text/plain;charset=utf-8".
> [1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JCR-4766) JcrRemotingServlet should write application/json content for JSON response
[
https://issues.apache.org/jira/browse/JCR-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4766:
Description:
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
Reproduction:
- Create a node (e.g, hello) like the following (excerpt from [1]):
{code}
$ curl --request MKCOL --data @- --user name:pass \
http://localhost:8080/server/default/jcr:root/hello/
Hello, World!
2022-01-15T12:00:00.000Z
END
{code}
- Retrieve the node by JSON binding:
{code}
$ curl --user name:pass http://localhost:8080/server/default/jcr:root/hello.json
{code}
- The {{Content-Type}} response header should be "application/json" or one of
its compatibles.
[1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
was:
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
> JcrRemotingServlet should write application/json content for JSON response
> --
>
> Key: JCR-4766
> URL: https://issues.apache.org/jira/browse/JCR-4766
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.21.10
>Reporter: Woonsan Ko
>Priority: Minor
>
> When retrieving a JCR node using JSON binding like the following by appending
> '.json' to the path, the content-type of the response should have been
> {{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
> {{GET http://localhost:8080/server/default/jcr:root/hello.json}}
> Reproduction:
> - Create a node (e.g, hello) like the following (excerpt from [1]):
> {code}
> $ curl --request MKCOL --data @- --user name:pass \
>http://localhost:8080/server/default/jcr:root/hello/ < http://www.jcp.org/jcr/sv/1.0;>
>
> Hello, World!
>
>
> 2022-01-15T12:00:00.000Z
>
>
> END
> {code}
> - Retrieve the node by JSON binding:
> {code}
> $ curl --user name:pass
> http://localhost:8080/server/default/jcr:root/hello.json
> {code}
> - The {{Content-Type}} response header should be "application/json" or one of
> its compatibles.
> [1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JCR-4766) JcrRemotingServlet should write application/json content for JSON response
[
https://issues.apache.org/jira/browse/JCR-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4766:
Description:
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
Reproduction:
- Create a node (e.g, hello) like the following (excerpt from [1]):
{code}
$ curl --request MKCOL --data @- --user name:pass \
http://localhost:8080/server/default/jcr:root/hello/
Hello, World!
2022-01-15T12:00:00.000Z
END
{code}
- Retrieve the node by JSON binding:
{code}
$ curl -i --user admin:admin
http://localhost:8080/server/default/jcr:root/hello.json
{code}
- The {{Content-Type}} response header should be "application/json" or one of
its compatibles.
[1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
was:
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
Reproduction:
- Create a node (e.g, hello) like the following (excerpt from [1]):
{code}
$ curl --request MKCOL --data @- --user name:pass \
http://localhost:8080/server/default/jcr:root/hello/
Hello, World!
2022-01-15T12:00:00.000Z
END
{code}
- Retrieve the node by JSON binding:
{code}
$ curl --user name:pass http://localhost:8080/server/default/jcr:root/hello.json
{code}
- The {{Content-Type}} response header should be "application/json" or one of
its compatibles.
[1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
> JcrRemotingServlet should write application/json content for JSON response
> --
>
> Key: JCR-4766
> URL: https://issues.apache.org/jira/browse/JCR-4766
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.21.10
>Reporter: Woonsan Ko
>Priority: Minor
>
> When retrieving a JCR node using JSON binding like the following by appending
> '.json' to the path, the content-type of the response should have been
> {{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
> {{GET http://localhost:8080/server/default/jcr:root/hello.json}}
> Reproduction:
> - Create a node (e.g, hello) like the following (excerpt from [1]):
> {code}
> $ curl --request MKCOL --data @- --user name:pass \
>http://localhost:8080/server/default/jcr:root/hello/ < http://www.jcp.org/jcr/sv/1.0;>
>
> Hello, World!
>
>
> 2022-01-15T12:00:00.000Z
>
>
> END
> {code}
> - Retrieve the node by JSON binding:
> {code}
> $ curl -i --user admin:admin
> http://localhost:8080/server/default/jcr:root/hello.json
> {code}
> - The {{Content-Type}} response header should be "application/json" or one of
> its compatibles.
> [1] https://jukkaz.wordpress.com/2009/11/24/jackrabbit-over-http/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (JCR-4766) JcrRemotingServlet should write application/json content for JSON response
Woonsan Ko created JCR-4766:
---
Summary: JcrRemotingServlet should write application/json content
for JSON response
Key: JCR-4766
URL: https://issues.apache.org/jira/browse/JCR-4766
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr-server
Affects Versions: 2.21.10
Reporter: Woonsan Ko
When retrieving a JCR node using JSON binding like the following by appending
'.json' to the path, the content-type of the response should have been
{{application/json}}, instead of the current {{text/plain;charset=utf-8}}.
{{GET http://localhost:8080/server/default/jcr:root/hello.json}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko reassigned JCR-4491: --- Assignee: Julian Reschke (was: Woonsan Ko) > Upgrade Commons VFS to 2.6 > -- > > Key: JCR-4491 > URL: https://issues.apache.org/jira/browse/JCR-4491 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Woonsan Ko >Assignee: Julian Reschke >Priority: Major > Labels: candidate_jcr_2_16 > Fix For: 2.21.0, 2.22, 2.20.3 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266698#comment-17266698 ] Woonsan Ko commented on JCR-4491: - Hi [~reschke], I've verified that everything works fine with the commons-vfs2 upgrade in JR 2.20.3-SNAPSHOT in my test demo project [1]. Thanks a lot! Woonsan [1] https://github.com/woonsanko/hippo-davstore-demo#option-2-install-and-run-an-example-webdav-server > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Labels: candidate_jcr_2_16 > Fix For: 2.21.0, 2.22, 2.20.3 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264955#comment-17264955 ] Woonsan Ko commented on JCR-4491: - [~reschke], will do before next week and update. Cheers! > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Labels: candidate_jcr_2_16 > Fix For: 2.21.0, 2.22, 2.20.3 > > > 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 or later. > 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)
[jira] [Comment Edited] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238904#comment-17238904 ] Woonsan Ko edited comment on JCR-4491 at 11/26/20, 1:53 AM: Hi [~reschke], I'd like to verify the fix in 2.20 too once you backported this, through unit tests and integration tests in my demo project. I'll keep watching this ticket and update this ticket with my tests later on. Thanks! Woonsan was (Author: woonsan): Hi [~reschke], I'd like to ensure the fix in 2.20 once backported through unit tests and integration tests with my demo. I'll keep watching this ticket and update with my tests later on. Woonsan > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Labels: candidate_jcr_2_20 > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238904#comment-17238904 ] Woonsan Ko commented on JCR-4491: - Hi [~reschke], I'd like to ensure the fix in 2.20 once backported through unit tests and integration tests with my demo. I'll keep watching this ticket and update with my tests later on. Woonsan > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Labels: candidate_jcr_2_20 > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238797#comment-17238797 ] Woonsan Ko commented on JCR-4491: - [~reschke], yes, it would really great to backport it to 2.20. I can do that and ask for your review in a day. Or please proceed for the coming release. Thanks a lot for noticing this! Cheers, woonsan > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Labels: candidate_jcr_2_20 > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072760#comment-17072760 ] Woonsan Ko commented on JCR-4491: - Thanks [~reschke]! I've just requested to use 2.20.0 instead. See VFS-756. Regards, Woonsan > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Resolved] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko resolved JCR-4491. - Resolution: Fixed > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033354#comment-17033354 ] Woonsan Ko commented on JCR-4491: - Fixed: r1873840. Unit tests passed and I've also verified it working in my test project too with (1) SFTP and (2) WebDAV backends: - https://github.com/woonsanko/hippo-davstore-demo Regards, Woonsan > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Commented] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031976#comment-17031976 ] Woonsan Ko commented on JCR-4491: - Will do this weekend and update this. Thanks! > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Updated] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated JCR-4491: Summary: Upgrade Commons VFS to 2.6 (was: Upgrade Commons VFS to 2.5) > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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)
[jira] [Updated] (JCR-4491) Upgrade Commons VFS to 2.6
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated JCR-4491: Description: 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 or later. So, once Commons VFS 2.5.0+ is released, upgrade the dependency and check VFSDataStore with WebDAV backend working fine. was: 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. > Upgrade Commons VFS to 2.6 > -- > > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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 or later. > 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)
[jira] [Updated] (JCR-4491) Upgrade Commons VFS to 2.5
[ https://issues.apache.org/jira/browse/JCR-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated JCR-4491: Fix Version/s: 2.22 2.21.0 > 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 >Priority: Major > Fix For: 2.21.0, 2.22 > > > 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)
[jira] [Created] (JCR-4491) Upgrade Commons VFS to 2.5
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)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927364#comment-16927364
]
Woonsan Ko commented on JCR-4458:
-
That makes sense to me.
Cheers,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_jcr_2_18
> Fix For: 2.20, 2.19.5
>
> Attachments: JCR-4458.diff
>
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4475) Improve o.a.j.jcr2dav.RepositoryStubImpl to test with custom servlet path mapping
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
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
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919617#comment-16919617
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
Sure. It will be easy because I already submitted a patch only for
RepositoryStubImpl separately in JCR-4460 :
https://issues.apache.org/jira/secure/attachment/12975997/12975997_servlet_path_prefix.patch
I'll remove the changes of RepositoryStubImpl in the PR and notify you.
Thanks,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918656#comment-16918656
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
Yes, the changes fix the test case #4 in my last comment in JCR-4460: "With
custom context path". And the other changes in RepositoryStubImpl are
improvements to allow servlet path configurations as well.
And the reason why I ruled out the option of "changing/extending APIs in a way
that would avoid the thread local" is that I thought another approach I took in
https://github.com/apache/jackrabbit/pull/84 is hard to understand in
maintenance perspective and is by itself kind of indirect inference of context
path anyway. So, I thought it seems better to directly access and use the
request to determine the context path and easier to maintain..
Regards,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.20
>
> Attachments: JCR-4458.diff
>
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911192#comment-16911192
]
Woonsan Ko commented on JCR-4458:
-
Hi [~julian.resc...@gmx.de] ,
No objection. :-) Please go ahead.
Best, Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895685#comment-16895685
]
Woonsan Ko 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
[
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
[
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
[
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; \
>.--user="admin:admin"
...
exit or quit leaves program.
help lists commands.
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894062#comment-16894062
]
Woonsan Ko commented on JCR-4458:
-
I thought it would be straightforward by prepending the contextPath to the
given resource path prefix in the servlet with my patch for JCR-4460.
However, it seems more complex.
For example, some classes are removing the contextPath before resolving
locations, and some are concatenating the href prefix (including the
contextPath) and the path prefix (starting with contextPath again) when making
child node paths, and so on. There seems to have been some inconsistencies...
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path
[
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
[
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
[
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
[
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)
[jira] [Commented] (JCR-4460) allow to run remoted conformance tests with a custom servlet context path
[
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
[
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
[
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)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890599#comment-16890599
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
Could you please review my PR?
- https://github.com/apache/jackrabbit/pull/84
I think {{JcrPrivilegeReport}} needs to convert the input href to any of these
anyway:
# an absolute URL (e.g, {{http://localhost:8080/cms/server/default/jcr:root}}),
# a context relative path (e.g, {{/server/default/jcr:root}}),
# or just a JCR resource path (e.g, {{/default/jcr:root}}).
The third option seems best to me, and it seems to fix the problem case.
Regards,
Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16889237#comment-16889237
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
After pulling the latest from trunk branch, I tried to reproduce it with the
regular integration tests with `{{mvn clean install -PintegrationTesting
-DWebDAVServletContext="/foobar/"}}`, but the build was successful.
Did I miss something?
Regards, Woonsan
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886130#comment-16886130
]
Woonsan Ko commented on JCR-4458:
-
Thanks, [~reschke]! I'll make jcr-shell work on Windows and let you know soon.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878542#comment-16878542
]
Woonsan Ko commented on JCR-4458:
-
Indeed. Seems like the same issue! :-)
Thanks a lot for your attention! I couldn’t figure out an easy solution
yesterday as JcrPrivilegeReport doesn’t have a direct access to servletContext.
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
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="admin:admin"
...
exit or quit leaves program.
help lists commands.
jcr-shell:> ls
done.
[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878190#comment-16878190
]
Woonsan Ko 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.
---
NameType
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878190#comment-16878190
]
Woonsan Ko commented on JCR-4458:
-
If you want, you can reproduce the problem easily with the two tools [1,2] to
reproduce the problem.
h2. A problem case
- Start Jackrabbit server with a servlet context path ("/cms") using [1]:
{noformat}
$ export SERVER_SERVLET_CONTEXT_PATH=/cms
$ java \
> -Drepository.home=target/jackrabbit-repository \
> -Drepository.config=conf/simple-repository.xml \
> -Dloader.path=lib/ \
> -jar target/jackrabbit-boot-0.0.1-SNAPSHOT.jar
...
{noformat}
- Start JCR Shell [2] as a JCR/WebDAV client, list nodes in the root and try to
import an XML:
{noformat}
$ java -jar target/jcrshell-2.0.4-SNAPSHOT.jar \
>.--server="http://localhost:8080/cms/server; \
>.--user="admin:admin"
...
exit or quit leaves program.
help lists commands.
jcr-shell:> ls
done.
---
NameType
---
jcr:system rep:system
rep:policy rep:ACL
---
Command completed in 981 msecs.
admin:/> nodeimport hello.xml
UnsupportedRepositoryOperationException while executing nodeimport: Missing
implementation
admin:/>
{noformat}
- It fails with an {{UnsupportedRepositoryOperationException}}. The server [1]
prints the following stack traces:
{noformat}
{noformat}
2019-07-03 17:59:52.794 ERROR 9604 --- [nio-8080-exec-1]
o.a.c.c.C.[.[.[.[jcrRemotingServlet] : Servlet.service() for servlet
[jcrRemotingServlet] in context with path [/cms] threw exception
java.lang.IllegalArgumentException: Unexpected format of resource path:
/cms/server/default/jcr:root (workspace: /cms)
at
org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(DavLocatorFactoryImpl.java:65)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.getRepositoryPath(AbstractLocatorFactory.java:366)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.addResponses(JcrPrivilegeReport.java:130)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.init(JcrPrivilegeReport.java:114)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.version.report.ReportType.createReport(ReportType.java:72)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.AbstractResource.getReport(AbstractResource.java:513)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.WorkspaceResourceImpl.getReport(WorkspaceResourceImpl.java:88)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doReport(AbstractWebdavServlet.java:1117)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:416)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:305)
~[jackrabbit-webdav-2.18.2.jar!/:na]
...
{noformat}
-
[1] Jackrabbit-boot, https://github.com/woonsan/jackrabbit-boot
(A simple, minimalistic Jackrabbit 2 standalone application example using
Spring-boot like Jackrabbit Standalone.)
[2] https://bloomreach-forge.github.io/jcr-shell/
(An open source shell project to access remote JCR using JCR over WebDAV
protocol.)
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server;;
> Jcr2davRepositoryFactory factory = new
[jira] [Updated] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels: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
[
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
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)
[jira] [Closed] (JCR-4421) Release Jackrabbit 2.19.2
[ 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
[ 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)
[jira] [Closed] (JCR-4422) Update httpclient/mime dependencies to 4.5.8
[ 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
[ 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
[ 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
[
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
[ 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)
[jira] [Created] (JCR-4421) Release Jackrabbit 2.19.2
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)
[jira] [Resolved] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
[ 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
[ 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
[ 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
[
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
[
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)
[jira] [Assigned] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
[ https://issues.apache.org/jira/browse/JCR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko reassigned JCR-4401: --- Assignee: Woonsan Ko > 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] [Created] (JCR-4401) Split jackrabbit-standalone to jackrabbit-standalone-components and the rest
Woonsan Ko created JCR-4401: --- Summary: 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 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-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607177#comment-16607177
]
Woonsan Ko commented on JCR-4369:
-
Thank you very much! :-)
Cheers,
Woonsan
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-aws-ext
>Affects Versions: 2.16.3, 2.17.5
>Reporter: Woonsan Ko
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 2.18, 2.17.6
>
>
> While using S3DataStore, the following logs are observed occasionally:
> {noformat}
> WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
> Not all bytes were read from the S3ObjectInputStream,
> aborting HTTP connection. This is likely an error and may result in
> sub-optimal behavior. Request only the bytes you need via a ranged
> GET or drain the input stream after use.
> {noformat}
> The warning logs are being left not only by HTTP processing threads, but also
> by background threads, which made me think of the possibility of some
> 'issues' in {{S3DataStore}} implementation. Not just caused by a broken http
> connection by client.
> By the way, this issue is not a major one as AWS toolkit seems to just give a
> warning as _recommendation_ in that case, with closing the underlying
> HttpRequest object properly. So, there's no issue in functionality for the
> record. It's only about 'warning' message and possible sub-optimal http
> request handling under the hood (in AWS toolkit side).
> After looking at the code, I noticed that
> {{CachingDataStore#proactiveCaching}} is enabled by default, which means the
> {{S3DataStore}} tries to _proactively_ download the binary content,
> asynchronously in a new thread, even when accessing metadata through
> {{#getLastModified(...) and #getLength(...).
> Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads
> content (in other words get an input stream on an {{S3Object}}, it is
> recommended to _read_ all data or _abort_ the input stream. Just to _close_
> the input stream is not good enough in AWS SDK perspective, resulting in the
> warning. See {{S3AbortableInputStream#close()}} method. \[1\]
> Therefore, some S3 related classes (such as
> {{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
> {{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
> the following:
> - If local cache file doesn't exist or it's on purge mode, it works as it
> does: Just copy everything to local cache file and close it.
> - Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
> The issue is a known one in AWS toolkit. \[2,3\] It seems like clients using
> the toolkit needs to _abort_ the input stream if it doesn't want to read data
> fully.
> \[1\]
> https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
> \[2\] https://github.com/aws/aws-sdk-java/issues/1211
> \[3\] https://github.com/aws/aws-sdk-java/issues/1657
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Fix Version/s: 2.17.6
2.18
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-aws-ext
>Affects Versions: 2.16.3, 2.17.5
>Reporter: Woonsan Ko
>Priority: Minor
> Fix For: 2.18, 2.17.6
>
>
> While using S3DataStore, the following logs are observed occasionally:
> {noformat}
> WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
> Not all bytes were read from the S3ObjectInputStream,
> aborting HTTP connection. This is likely an error and may result in
> sub-optimal behavior. Request only the bytes you need via a ranged
> GET or drain the input stream after use.
> {noformat}
> The warning logs are being left not only by HTTP processing threads, but also
> by background threads, which made me think of the possibility of some
> 'issues' in {{S3DataStore}} implementation. Not just caused by a broken http
> connection by client.
> By the way, this issue is not a major one as AWS toolkit seems to just give a
> warning as _recommendation_ in that case, with closing the underlying
> HttpRequest object properly. So, there's no issue in functionality for the
> record. It's only about 'warning' message and possible sub-optimal http
> request handling under the hood (in AWS toolkit side).
> After looking at the code, I noticed that
> {{CachingDataStore#proactiveCaching}} is enabled by default, which means the
> {{S3DataStore}} tries to _proactively_ download the binary content,
> asynchronously in a new thread, even when accessing metadata through
> {{#getLastModified(...) and #getLength(...).
> Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads
> content (in other words get an input stream on an {{S3Object}}, it is
> recommended to _read_ all data or _abort_ the input stream. Just to _close_
> the input stream is not good enough in AWS SDK perspective, resulting in the
> warning. See {{S3AbortableInputStream#close()}} method. \[1\]
> Therefore, some S3 related classes (such as
> {{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
> {{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
> the following:
> - If local cache file doesn't exist or it's on purge mode, it works as it
> does: Just copy everything to local cache file and close it.
> - Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
> The issue is a known one in AWS toolkit. \[2,3\] It seems like clients using
> the toolkit needs to _abort_ the input stream if it doesn't want to read data
> fully.
> \[1\]
> https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
> \[2\] https://github.com/aws/aws-sdk-java/issues/1211
> \[3\] https://github.com/aws/aws-sdk-java/issues/1657
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16604370#comment-16604370
]
Woonsan Ko commented on JCR-4369:
-
I'm preparing a pull request. Hope to provide one soon.
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-aws-ext
>Affects Versions: 2.16.3, 2.17.5
>Reporter: Woonsan Ko
>Priority: Minor
>
> While using S3DataStore, the following logs are observed occasionally:
> {noformat}
> WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
> Not all bytes were read from the S3ObjectInputStream,
> aborting HTTP connection. This is likely an error and may result in
> sub-optimal behavior. Request only the bytes you need via a ranged
> GET or drain the input stream after use.
> {noformat}
> The warning logs are being left not only by HTTP processing threads, but also
> by background threads, which made me think of the possibility of some
> 'issues' in {{S3DataStore}} implementation. Not just caused by a broken http
> connection by client.
> By the way, this issue is not a major one as AWS toolkit seems to just give a
> warning as _recommendation_ in that case, with closing the underlying
> HttpRequest object properly. So, there's no issue in functionality for the
> record. It's only about 'warning' message and possible sub-optimal http
> request handling under the hood (in AWS toolkit side).
> After looking at the code, I noticed that
> {{CachingDataStore#proactiveCaching}} is enabled by default, which means the
> {{S3DataStore}} tries to _proactively_ download the binary content,
> asynchronously in a new thread, even when accessing metadata through
> {{#getLastModified(...) and #getLength(...).
> Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads
> content (in other words get an input stream on an {{S3Object}}, it is
> recommended to _read_ all data or _abort_ the input stream. Just to _close_
> the input stream is not good enough in AWS SDK perspective, resulting in the
> warning. See {{S3AbortableInputStream#close()}} method. \[1\]
> Therefore, some S3 related classes (such as
> {{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
> {{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
> the following:
> - If local cache file doesn't exist or it's on purge mode, it works as it
> does: Just copy everything to local cache file and close it.
> - Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
> The issue is a known one in AWS toolkit. \[2,3\] It seems like clients using
> the toolkit needs to _abort_ the input stream if it doesn't want to read data
> fully.
> \[1\]
> https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
> \[2\] https://github.com/aws/aws-sdk-java/issues/1211
> \[3\] https://github.com/aws/aws-sdk-java/issues/1657
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record. It's only about 'warning' message and possible sub-optimal http request
handling under the hood (in AWS toolkit side).
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, some S3 related classes (such as
{{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
{{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
The issue is a known one in AWS toolkit. \[2,3\] It seems like clients using
the toolkit needs to _abort_ the input stream if it doesn't want to read data
fully.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1211
\[3\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, some S3 related classes (such as
{{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
{{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
The issue is a known one in AWS toolkit. \[2,3\] It seems like clients using
the toolkit needs to _abort_ the input stream if it doesn't want to read data
fully.
\[1\]
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, some S3 related classes (such as
{{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
{{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
The issue is a known one in AWS toolkit. \[2,3\] It seems like clients using
the toolkit needs to _abort_ the input stream if it doesn't want to read data
fully.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1211
\[3\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, some S3 related classes (such as
{{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
{{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data fully.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, some S3 related classes (such as
{{org.apache.jackrabbit.core.data.LocalCache#store(String, InputStream)}},
{{CachingDataStore#getStream(DataIdentifier)}}, etc.) should be improved like
the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the underlying {{S3ObjectInputStream}}.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data fully.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data fully.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL:
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data fully.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
>
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3DataStore}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just to _close_ the input stream
is not good enough in AWS SDK perspective, resulting in the warning. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
>
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content, asynchronously in a new thread, even when
accessing metadata through {{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
>
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3DataStore}} implementation. Not just caused by a broken http connection
by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3Backend}} implementation. Not just caused by a broken http connection by
client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
>
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by HTTP processing threads, but also
by background threads, which made me think of the possibility of some 'issues'
in {{S3Backend}} implementation. Not just caused by a broken http connection by
client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by both HTTP processing threads, but
also by background threads, which made me think of the possibility of some
'issues' in {{S3Backend}} implementation. Not just caused by a broken http
connection by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
>
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by both HTTP processing threads, but
also by background threads, which made me think of the possibility of some
'issues' in {{S3Backend}} implementation. Not just caused by a broken http
connection by client.
By the way, this issue is not a major one as AWS toolkit seems to just give a
warning as _recommendation_ in that case, with closing the underlying
HttpRequest object properly. So, there's no issue in functionality for the
record.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by both HTTP processing threads, but
also by background threads, which made me think of the possibility of some
'issues' in {{S3Backend}} implementation. Not just caused by a broken http
connection by client.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-aws-ext
>Affects Versions: 2.16.3, 2.17.5
>
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Affects Version/s: 2.16.3
2.17.5
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-aws-ext
>Affects Versions: 2.16.3, 2.17.5
>Reporter: Woonsan Ko
>Priority: Minor
>
> While using S3DataStore, the following logs are observed occasionally:
> {noformat}
> WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
> Not all bytes were read from the S3ObjectInputStream,
> aborting HTTP connection. This is likely an error and may result in
> sub-optimal behavior. Request only the bytes you need via a ranged
> GET or drain the input stream after use.
> {noformat}
> The warning logs are being left not only by both HTTP processing threads, but
> also by background threads, which made me think of the possibility of some
> 'issues' in {{S3Backend}} implementation. Not just caused by a broken http
> connection by client.
> After looking at the code, I noticed that
> {{CachingDataStore#proactiveCaching}} is enabled by default, which means the
> {{S3DataStore}} tries to _proactively_ download the binary content even when
> accessing metadata through {{#getLastModified(...) and #getLength(...).
> Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
> (in other words get an input stream on an {{S3Object}}, it is recommended to
> _read_ all data or _abort_ the input stream. Just closing the input stream is
> not good enough in AWS SDK perspective, which gives a warning if the input
> stream was not fully read or not aborted explicitly. See
> {{S3AbortableInputStream#close()}} method. \[1\]
> Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
> InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}})
> could be improved like the following:
> - If local cache file doesn't exist or it's on purge mode, it works as it
> does: Just copy everything to local cache file and close it.
> - Otherwise, it should {{abort}} the input stream.
> The issue is a known one in AWS toolkit. \[2\] It seems like clients using
> the toolkit needs to _abort_ the input stream if it doesn't want to read data
> fully. \[2\]
> \[1\]
> https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
> \[2\] https://github.com/aws/aws-sdk-java/issues/1657
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCR-4369) Avoid S3 Incomplete Read Warning
[
https://issues.apache.org/jira/browse/JCR-4369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Woonsan Ko updated JCR-4369:
Description:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream,
aborting HTTP connection. This is likely an error and may result in sub-optimal
behavior. Request only the bytes you need via a ranged
GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by both HTTP processing threads, but
also by background threads, which made me think of the possibility of some
'issues' in {{S3Backend}} implementation. Not just caused by a broken http
connection by client.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
The issue is a known one in AWS toolkit. \[2\] It seems like clients using the
toolkit needs to _abort_ the input stream if it doesn't want to read data
fully. \[2\]
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
\[2\] https://github.com/aws/aws-sdk-java/issues/1657
was:
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream, aborting HTTP connection.
This is likely an error and may result in sub-optimal behavior. Request only
the bytes you need via a ranged GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by both HTTP processing threads, but
also by background threads, which made me think of the possibility of some
'issues' in {{S3Backend}} implementation. Not just caused by a broken http
connection by client.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
> Avoid S3 Incomplete Read Warning
>
>
> Key: JCR-4369
> URL: https://issues.apache.org/jira/browse/JCR-4369
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-aws-ext
>Affects Versions: 2.16.3, 2.17.5
>Reporter: Woonsan Ko
>Priority: Minor
>
> While using S3DataStore, the following logs are observed occasionally:
> {noformat}
> WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
> Not all bytes were read from the S3ObjectInputStream,
> aborting HTTP connection. This is likely an error and may result in
> sub-optimal behavior. Request only the bytes you need via a ranged
> GET or drain the input stream
[jira] [Created] (JCR-4369) Avoid S3 Incomplete Read Warning
Woonsan Ko created JCR-4369:
---
Summary: Avoid S3 Incomplete Read Warning
Key: JCR-4369
URL: https://issues.apache.org/jira/browse/JCR-4369
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-aws-ext
Reporter: Woonsan Ko
While using S3DataStore, the following logs are observed occasionally:
{noformat}
WARN [com.amazonaws.services.s3.internal.S3AbortableInputStream.close():178]
Not all bytes were read from the S3ObjectInputStream, aborting HTTP connection.
This is likely an error and may result in sub-optimal behavior. Request only
the bytes you need via a ranged GET or drain the input stream after use.
{noformat}
The warning logs are being left not only by both HTTP processing threads, but
also by background threads, which made me think of the possibility of some
'issues' in {{S3Backend}} implementation. Not just caused by a broken http
connection by client.
After looking at the code, I noticed that {{CachingDataStore#proactiveCaching}}
is enabled by default, which means the {{S3DataStore}} tries to _proactively_
download the binary content even when accessing metadata through
{{#getLastModified(...) and #getLength(...).
Anyway, the _minor_ problem is now, whenever the {{S3Backend}} reads content
(in other words get an input stream on an {{S3Object}}, it is recommended to
_read_ all data or _abort_ the input stream. Just closing the input stream is
not good enough in AWS SDK perspective, which gives a warning if the input
stream was not fully read or not aborted explicitly. See
{{S3AbortableInputStream#close()}} method. \[1\]
Therefore, {{org.apache.jackrabbit.core.data.LocalCache#store(String,
InputStream)}} (used by {{CachingDataStore#getStream(DataIdentifier)}}) could
be improved like the following:
- If local cache file doesn't exist or it's on purge mode, it works as it does:
Just copy everything to local cache file and close it.
- Otherwise, it should {{abort}} the input stream.
\[1\]
https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/internal/S3AbortableInputStream.java#L174-L187
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4354) VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
[
https://issues.apache.org/jira/browse/JCR-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597474#comment-16597474
]
Woonsan Ko commented on JCR-4354:
-
Thank you very much!
Woonsan
> VFS (commons-vfs) based FileSystem for VFS backend based Persistence Manager
>
>
> Key: JCR-4354
> URL: https://issues.apache.org/jira/browse/JCR-4354
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-vfs-ext
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 2.18, 2.17.6
>
> Attachments: JCR-4354.diff
>
>
> I think it would be nice to have a VFS (commons-vfs) based {{FileSystem}}
> which then can be used by {{BundleFsPersistenceManager}}.
> For example, I have worked with a Jackrabbit based WCMS product which
> recommends using one of {{BundleDbPersistenceManager}} components for both
> workspaces and version, which makes it easier for clustering.
> One typical problem is that the version storage in DBMS keeps increasing, so
> as a result we've recommended cleaning up older version items periodically.
> (You may google "cms version cleaner" for more info.)
> In this case, if they were able to configure a VFS based {{FileSystem}} and
> the generic {{PersistenceManager}}, {{BundleFsPersistenceManager}}, for the
> versions, their DB size would keep small enough, and they may keep the
> version items almost infinitely. Actually versioning are used relatively less
> than other normal functionalities such as content retrieval and searching,
> only when authoring users publish a document in our case. So, keeping version
> data separately from database wouldn't be a problem, as long as it supports
> easier clustering (through WebDAV or SFTP in this option).
> Another possible use case is that some people may use VFS based solution for
> both workspaces and version, backed by a clustered WebDAV server or SFTP
> server. They can use VFS-based DataStore provided by JCR-3975 as well. This
> would increase architectural options around Jackrabbit ecosystem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
