[jira] [Commented] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921794#comment-16921794 ] Tobias Bocanegra commented on JCRVLT-359: - I think this is correct. > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921777#comment-16921777 ] Alexei Krainiouk edited comment on JCRVLT-359 at 9/4/19 12:20 AM: -- [~tripod] Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. As far as I understand for CUG case [MERGE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L65] and [MERGE_PRESERVE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L97] are essentially the same. I.E. in both cases the resulting principal list is a union of pre-existing principals and those that come in the package. Please correct me if I am wrong. was (Author: akrainiouk): [~tripod] Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. As far as I understand for CUG case [AccessControlHandling.MERGE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L65] and [AccessControlHandling.MERGE_PRESERVE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L97] are essentially the same. I.E. in both cases the resulting principal list is a union of pre-existing principals and those that come in the package. Please correct me if I am wrong. > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921777#comment-16921777 ] Alexei Krainiouk edited comment on JCRVLT-359 at 9/4/19 12:19 AM: -- [~tripod] Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. As far as I understand for CUG case [AccessControlHandling.MERGE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L65] and [AccessControlHandling.MERGE_PRESERVE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L97] are essentially the same. Please correct me if I am wrong. I.E. in both cases the resulting principal list is a union of pre-existing principals and those that come in the package. was (Author: akrainiouk): Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921777#comment-16921777 ] Alexei Krainiouk edited comment on JCRVLT-359 at 9/4/19 12:19 AM: -- [~tripod] Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. As far as I understand for CUG case [AccessControlHandling.MERGE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L65] and [AccessControlHandling.MERGE_PRESERVE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L97] are essentially the same. I.E. in both cases the resulting principal list is a union of pre-existing principals and those that come in the package. Please correct me if I am wrong. was (Author: akrainiouk): [~tripod] Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. As far as I understand for CUG case [AccessControlHandling.MERGE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L65] and [AccessControlHandling.MERGE_PRESERVE|https://github.com/apache/jackrabbit-filevault/blob/c6a8b816a31f3347113b8a8d4eac281faf0a6d5b/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/AccessControlHandling.java#L97] are essentially the same. Please correct me if I am wrong. I.E. in both cases the resulting principal list is a union of pre-existing principals and those that come in the package. > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCRVLT-359) Provide separate option to control handling of rep:cugPolicy nodes.
[ https://issues.apache.org/jira/browse/JCRVLT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921777#comment-16921777 ] Alexei Krainiouk commented on JCRVLT-359: - Added [unit tests|https://github.com/apache/jackrabbit-filevault/pull/56/commits/6fafa8afbfc4fb4d6de7262bedc7cf15f5bc30a0] for cugHandling. > Provide separate option to control handling of rep:cugPolicy nodes. > --- > > Key: JCRVLT-359 > URL: https://issues.apache.org/jira/browse/JCRVLT-359 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.2.8 >Reporter: Alexei Krainiouk >Priority: Major > > Currently handling of rep:cugPolicy nodes is controlled by aclHandling > configuration option that equally affects ACLs and CUGs. We need to control > them separately as for replication that is based on sling-distribution we > need to ignore ACLs while overwriting CUGs -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCR-4459) Basic Authentication for HTTPS URIs does not work
[ https://issues.apache.org/jira/browse/JCR-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921489#comment-16921489 ] Konrad Windszus commented on JCR-4459: -- There is still some discussion about the minimum version for the next Filevault at https://lists.apache.org/thread.html/711e218e0c9f7be5618999b021c6fc7a9d570ea68467bc533976958d@%3Cdev.jackrabbit.apache.org%3E. Let's see what the outcome is. > Basic Authentication for HTTPS URIs does not work > - > > Key: JCR-4459 > URL: https://issues.apache.org/jira/browse/JCR-4459 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-spi2dav >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_jcr_2_14 > Fix For: 2.20, 2.16.5, 2.19.4, 2.18.3 > > > ...because the auth cache is keyed by httpHost, and in the constructor, we > leave out the URI scheme. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCR-4459) Basic Authentication for HTTPS URIs does not work
[ https://issues.apache.org/jira/browse/JCR-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921475#comment-16921475 ] Julian Reschke commented on JCR-4459: - Yes, that's why it says "candidate_jcr_2_14". When do you need it? (I could cut 2.14 once I'm done with 2.16.5; but only if there's an actual need...) > Basic Authentication for HTTPS URIs does not work > - > > Key: JCR-4459 > URL: https://issues.apache.org/jira/browse/JCR-4459 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-spi2dav >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_jcr_2_14 > Fix For: 2.20, 2.16.5, 2.19.4, 2.18.3 > > > ...because the auth cache is keyed by httpHost, and in the constructor, we > leave out the URI scheme. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCR-4459) Basic Authentication for HTTPS URIs does not work
[ https://issues.apache.org/jira/browse/JCR-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921467#comment-16921467 ] Konrad Windszus commented on JCR-4459: -- [~reschke] Is a fix for 2.14 planned (as that was the last version still supporting Java 7)? > Basic Authentication for HTTPS URIs does not work > - > > Key: JCR-4459 > URL: https://issues.apache.org/jira/browse/JCR-4459 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-spi2dav >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_jcr_2_14 > Fix For: 2.20, 2.16.5, 2.19.4, 2.18.3 > > > ...because the auth cache is keyed by httpHost, and in the constructor, we > leave out the URI scheme. -- This message was sent by Atlassian Jira (v8.3.2#803003)
Re: FileVault: Require Java 8
I am a bit confused, Jackrabbit 2.16 requires Java 8 already and was already required with filevault 3.2.8 (https://github.com/apache/jackrabbit-filevault/blob/5104a49b4b0fcd25bfbcc202734cca490e55765d/parent/pom.xml#L43) Oak 1.6 on the other hand still supports Java 7 (it depends on Jackrabbit 2.14 -> https://github.com/apache/jackrabbit-oak/blob/024278e1e33935bb30729a36252a1c93cc0e0d18/oak-parent/pom.xml#L45) So why is the combination of Oak 1.6 / Jackrabbit 2.16 necessary? I would understand Oak 1.6 / Jackrabbit 2.14 (AEM 6.3, still supports Java 7). What should we now target for the next 3.x release? Thanks, Konrad > On 26. Aug 2019, at 19:54, Tobias Bocanegra wrote: > > Hi, > > The problem is, that we need oak 1.6 / jackrabbit 2.16 compatible version of > filevault. I think that > https://issues.apache.org/jira/browse/JCRVLT-340 might already changed that. > If so, we need to update > The major version and jump to 4.0.0, if filevault no longer works with oak > 1.16. > And then we also need to start a dedicated 3.x branch for back ports. > > Regards, Toby > > >> On 26 Aug 2019, at 05:00, Konrad Windszus wrote: >> >> Hi, currently FileVault is still supporting Java 7. >> But with https://issues.apache.org/jira/browse/JCRVLT-344 we implicitly >> require Java 8 (due to the dependency towards Oak 1.16 and Jackrabbit 2.18). >> Is it fine if with the next release version (3.2.10) we require Java 8? Or >> should we rather increase the second digit, i.e. release 3.4.0? >> >> Is Filevault using the same Odd/Even release policy as Jackrabbit/Oak? >> >> In any case I would strongly recommend to upgrade then also the FileVault >> Maven Plugin to Java 8. >> WDYT? >> Konrad >> >> >
Re: [VOTE] Release Apache Jackrabbit 2.16.5
[X] +1 Release this package as Apache Jackrabbit 2.16.5 ...where... [INFO] Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) [INFO] OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" [INFO] Java version: 1.8.0_45, vendor: Oracle Corporation [INFO] MAVEN_OPTS: -Xmx2048m -XX:MaxPermSize=1024m Best regards, Julian On 9/2/2019 10:25 AM, Julian Reschke wrote: A candidate for the Jackrabbit 2.16.5 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/2.16.5/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.16.5/ The SHA1 checksum of the archive is 531a0ff61c82b152bf864c68f5cef66b071b9038. A staged Maven repository is available for review at: https://repository.apache.org/ The command for running automated checks against this release candidate is: # run in SVN checkout of https://dist.apache.org/repos/dist/dev/jackrabbit/ $ sh check-release.sh 2.16.5 531a0ff61c82b152bf864c68f5cef66b071b9038 Please vote on releasing this package as Apache Jackrabbit 2.16.5. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit 2.16.5 [ ] -1 Do not release this package because... Best regards, Julian
[jira] [Updated] (JCRVLT-362) ZipStreamArchive does not expose correct input source to the META-INF resources
[
https://issues.apache.org/jira/browse/JCRVLT-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-362:
---
Status: Patch Available (was: Open)
PR: https://github.com/apache/jackrabbit-filevault/pull/57
> ZipStreamArchive does not expose correct input source to the META-INF
> resources
> ---
>
> Key: JCRVLT-362
> URL: https://issues.apache.org/jira/browse/JCRVLT-362
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Affects Versions: 3.2.8
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.2.10
>
>
> After calling {{open}} on a given {{ZipStreamArchive}} the {{getInputSource}}
> does not correctly expose access to the input stream of the entries below
> {{META-INF}}. This is due to the fact that the input stream of those entries
> are already consumed once
> https://github.com/apache/jackrabbit-filevault/blob/202e86a98226d1e3fda4a3f9278f174fc4c6094d/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/ZipStreamArchive.java#L158
> is reached. The solution would be to first copy to buffer/file and then read
> the meta inf from there.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
Re: [VOTE] Release Apache Jackrabbit 2.16.5
[X] +1 Release this package as Apache Jackrabbit 2.16.5 All checks ok where: [INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-04T04:39:06+09:00) [INFO] OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac" [INFO] Java version: 1.8.0_144, vendor: Oracle Corporation [INFO] MAVEN_OPTS: Thank you! Woonsan On Mon, Sep 2, 2019 at 5:25 PM Julian Reschke wrote: > > A candidate for the Jackrabbit 2.16.5 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/2.16.5/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.16.5/ > > The SHA1 checksum of the archive is > 531a0ff61c82b152bf864c68f5cef66b071b9038. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > # run in SVN checkout of > https://dist.apache.org/repos/dist/dev/jackrabbit/ > $ sh check-release.sh 2.16.5 531a0ff61c82b152bf864c68f5cef66b071b9038 > > Please vote on releasing this package as Apache Jackrabbit 2.16.5. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit 2.16.5 > [ ] -1 Do not release this package because... > > Best regards, Julian
