[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-754: -- Fix Version/s: 3.7.4 > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Priority: Major > Fix For: 3.7.4 > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Jackrabbit Filevault 3.7.4 Release Plan
FYI: I had to cancel the release as recent changes in Filevault breaks our check-release script (see https://issues.apache.org/jira/browse/JCRVLT-754). Best regards, Julian
[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-754: -- Description: Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated anymore; however, this is what is put into the generated vote template. The proper fix likely would be to put the SHA512 checksum into the vote template. Furthermore, the basename of the source artefact changed from"src" to "source-release". This needs to be adjusted in the check script. was: Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated anymore; however, this is what is put into the generated vote template. The proper fix likely would be to put the SHA512 checksum into the vote template. > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Priority: Major > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke moved JCR-5061 to JCRVLT-754: Key: JCRVLT-754 (was: JCR-5061) Project: Jackrabbit FileVault (was: Jackrabbit Content Repository) > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Priority: Major > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-754: -- Description: Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated anymore; however, this is what is put into the generated vote template. The proper fix likely would be to put the SHA512 checksum into the vote template. was:Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated anymore; however, this is what is put into the generated vote template. > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Priority: Major > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-5061) check-release does not work for filevault anymore
Julian Reschke created JCR-5061: --- Summary: check-release does not work for filevault anymore Key: JCR-5061 URL: https://issues.apache.org/jira/browse/JCR-5061 Project: Jackrabbit Content Repository Issue Type: Task Reporter: Julian Reschke Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated anymore; however, this is what is put into the generated vote template. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] OAK-10787: oak-lucene: backport fix for lucene-core vulnerability [jackrabbit-oak]
reschke merged PR #1443: URL: https://github.com/apache/jackrabbit-oak/pull/1443 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] OAK-10804 - Optimize check for hidden paths and clear warnings in NodeStateUtils class. [jackrabbit-oak]
nit0906 commented on code in PR #1461:
URL: https://github.com/apache/jackrabbit-oak/pull/1461#discussion_r1602563040
##
oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/state/NodeStateUtils.java:
##
@@ -53,12 +52,7 @@ public static boolean isHidden(@NotNull String name) {
* @return true if one of the nodes is hidden
*/
public static boolean isHiddenPath(@NotNull String path) {
-for (String n : PathUtils.elements(path)) {
-if (isHidden(n)) {
-return true;
-}
-}
-return false;
+return (!path.isEmpty() && path.charAt(0) == ':') ||
path.contains("/:");
Review Comment:
There's one behaviour change introduced by this PR - isHiddenPath no longer
checks if the path is valid or not. Earlier this used to happen when calling
PathUtils.elements.
This is not documented for this method, so in theory (might) be ok as well.
Otherwise the change looks ok to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-10804 - Optimize check for hidden paths and clear warnings in NodeStateUtils class. [jackrabbit-oak]
nit0906 commented on code in PR #1461:
URL: https://github.com/apache/jackrabbit-oak/pull/1461#discussion_r1602563040
##
oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/state/NodeStateUtils.java:
##
@@ -53,12 +52,7 @@ public static boolean isHidden(@NotNull String name) {
* @return true if one of the nodes is hidden
*/
public static boolean isHiddenPath(@NotNull String path) {
-for (String n : PathUtils.elements(path)) {
-if (isHidden(n)) {
-return true;
-}
-}
-return false;
+return (!path.isEmpty() && path.charAt(0) == ':') ||
path.contains("/:");
Review Comment:
There's one behaviour change introduced by this PR - isHiddenPath no longer
checks if he path is valid or not. Earlier this used to happen when calling
PathUtils.elements.
This is not documented for this method, so in theory (might) be ok as well.
Otherwise the change looks ok to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846706#comment-17846706
]
Julian Reschke commented on JCRVLT-753:
---
Re IT: actually, the system behaves as expected, so I wouldn't call it
"failing"...
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846704#comment-17846704
]
Konrad Windszus commented on JCRVLT-753:
[~dbanjac] Can you provide a failing IT in a PR?
However I don't have a clever idea how to solve this edge case as all options
outlined above by [~reschke] seem quite unexpected to the user either so any
other suggestions would be much appreciated.
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] OAK-6756: Convert oak-auth-external to OSGi R7 annotations [jackrabbit-oak]
anchela commented on code in PR #1371:
URL: https://github.com/apache/jackrabbit-oak/pull/1371#discussion_r1601919321
##
oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModuleFactory.java:
##
@@ -45,100 +37,123 @@
import org.apache.jackrabbit.oak.spi.whiteboard.Whiteboard;
import org.osgi.framework.BundleContext;
import org.osgi.service.component.ComponentContext;
+import org.osgi.service.component.annotations.Component;
+import org.osgi.service.component.annotations.Activate;
+import org.osgi.service.component.annotations.Deactivate;
+import org.osgi.service.component.annotations.ConfigurationPolicy;
+import org.osgi.service.component.annotations.Reference;
+import org.osgi.service.component.annotations.ReferencePolicy;
+import org.osgi.service.component.annotations.ReferenceCardinality;
+import org.osgi.service.metatype.annotations.Designate;
+import org.osgi.service.metatype.annotations.ObjectClassDefinition;
+import org.osgi.service.metatype.annotations.AttributeDefinition;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import static
org.apache.jackrabbit.oak.spi.security.authentication.external.basic.AutoMembershipConfig.PARAM_SYNC_HANDLER_NAME;
+
/**
* Implements a LoginModuleFactory that creates {@link ExternalLoginModule}s
and allows to configure login modules
* via OSGi config.
*/
@Component(
-label = "Apache Jackrabbit Oak External Login Module",
-metatype = true,
-policy = ConfigurationPolicy.REQUIRE,
-configurationFactory = true
+configurationPolicy = ConfigurationPolicy.REQUIRE,
+service = {
+LoginModuleFactory.class,
+SyncHandlerMapping.class
+},
+property = {
Review Comment:
@mbaedke , these 3 properties are also present as AttributeDefinitions in
the configuration below. what is the impact of having them listed here as well?
##
oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/principal/ExternalPrincipalConfiguration.java:
##
@@ -75,34 +74,59 @@
* @see https://issues.apache.org/jira/browse/OAK-4101;>OAK-4101
*/
@Component(
-metatype = true,
-label = "Apache Jackrabbit Oak External PrincipalConfiguration",
-immediate = true
+immediate = true,
+service = {
+PrincipalConfiguration.class,
+SecurityConfiguration.class
+},
+property = {
Review Comment:
same as above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-6756: Convert oak-auth-external to OSGi R7 annotations [jackrabbit-oak]
anchela commented on PR #1371: URL: https://github.com/apache/jackrabbit-oak/pull/1371#issuecomment-2112949606 @jsedding , thanks but honestly i am not sure that the new diff is actually good or still needs some work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] OAK-10739 : reverted static import of System.currentTimeMillis() [jackrabbit-oak]
rishabhdaim merged PR #1462: URL: https://github.com/apache/jackrabbit-oak/pull/1462 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846587#comment-17846587
]
Julian Reschke edited comment on JCRVLT-753 at 5/15/24 11:32 AM:
-
So how could this be avoided without changing any code?
- change the parent node to be mix:referencable as well
- change the jcr:content child node not to be referenceable
- avoid renaming of nodes
- manually removing the conflicting node before replication
was (Author: reschke):
So how could this be avoided without changing any code?
- change the parent node to be mix:referencable as well
- avoid renaming of nodes
- manually removing the conflicting node before replication
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846587#comment-17846587
]
Julian Reschke commented on JCRVLT-753:
---
So how could this be avoided without changing any code?
- change the parent node to be mix:referencable as well
- avoid renaming of nodes
- manually removing the conflicting node before replication
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] OAK-10739 : Provide support for FullGC in Mongo DocumentStore [jackrabbit-oak]
rishabhdaim commented on code in PR #1454:
URL: https://github.com/apache/jackrabbit-oak/pull/1454#discussion_r1601419791
##
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/util/LoggingDocumentStoreWrapper.java:
##
@@ -283,6 +283,7 @@ public T call() throws Exception {
}
@Override
+@NotNull
Review Comment:
IntelliJ warns about this missing `@NotNull` annotation since the interface
declared this method `@NotNull`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[PR] OAK-10739 : reverted static import of System.currentTimeMillis() [jackrabbit-oak]
rishabhdaim opened a new pull request, #1462: URL: https://github.com/apache/jackrabbit-oak/pull/1462 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] OAK-10792 : rename DetailedGC to FullGC [jackrabbit-oak]
rishabhdaim merged PR #1460: URL: https://github.com/apache/jackrabbit-oak/pull/1460 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] OAK-10788 - Indexing job downloader: shutdown gracefully all threads in case of failure [jackrabbit-oak]
nfsantos merged PR #1456: URL: https://github.com/apache/jackrabbit-oak/pull/1456 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Issues/OAK-10675 [jackrabbit-oak]
t-rana commented on code in PR #1385: URL: https://github.com/apache/jackrabbit-oak/pull/1385#discussion_r1601300901 ## oak-blob-cloud-azure/pom.xml: ## @@ -50,8 +69,23 @@ azure-storage, azure-keyvault-core, +azure-core, +azure-identity, +azure-json, guava, -jsr305 +jsr305, Review Comment: @reschke, we are using azure-identity library for migration to service principals from access key based authentication in azure. All these dependencies came transitively from azure-identity. I initially tried marking some of them as optional which helped in resolving the bundle to active state but when I configured the component to use service principals, it failed with NoClassDefFoundError exceptions meaning that they were indeed required at runtime and cannot be marked as optional. Attaching the file of errors that I got and the corresponding dependency embedded. [dependencies_list.pdf](https://github.com/apache/jackrabbit-oak/files/15319377/dependencies_list.pdf) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] OAK-10792 : rename DetailedGC to FullGC [jackrabbit-oak]
rishabhdaim opened a new pull request, #1460: URL: https://github.com/apache/jackrabbit-oak/pull/1460 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] OAK-10800: (oak-search-elastic) add mapping for DictionaryCompoundWord [jackrabbit-oak]
fabriziofortino merged PR #1450: URL: https://github.com/apache/jackrabbit-oak/pull/1450 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] OAK-10800: (oak-search-elastic) add mapping for DictionaryCompoundWord [jackrabbit-oak]
nfsantos commented on code in PR #1450:
URL: https://github.com/apache/jackrabbit-oak/pull/1450#discussion_r1601135655
##
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticCustomAnalyzerMappings.java:
##
@@ -112,78 +112,30 @@ protected interface ParameterTransformer {
LUCENE_ELASTIC_TRANSFORMERS = new LinkedHashMap<>();
LUCENE_ELASTIC_TRANSFORMERS.put(WordDelimiterFilterFactory.class,
luceneParams -> {
-if (luceneParams.containsKey("generateWordParts")) {
-luceneParams.put("generateWordParts",
Integer.parseInt(luceneParams.get("generateWordParts").toString()) == 1);
-}
-if (luceneParams.containsKey("generateNumberParts")) {
-luceneParams.put("generateNumberParts",
Integer.parseInt(luceneParams.get("generateNumberParts").toString()) == 1);
-}
-if (luceneParams.containsKey("catenateWords")) {
-luceneParams.put("catenateWords",
Integer.parseInt(luceneParams.get("catenateWords").toString()) == 1);
-}
-if (luceneParams.containsKey("catenateNumbers")) {
-luceneParams.put("catenateNumbers",
Integer.parseInt(luceneParams.get("catenateNumbers").toString()) == 1);
-}
-if (luceneParams.containsKey("catenateAll")) {
-luceneParams.put("catenateAll",
Integer.parseInt(luceneParams.get("catenateAll").toString()) == 1);
-}
-if (luceneParams.containsKey("splitOnCaseChange")) {
-luceneParams.put("splitOnCaseChange",
Integer.parseInt(luceneParams.get("splitOnCaseChange").toString()) == 1);
-}
-if (luceneParams.containsKey("preserveOriginal")) {
-luceneParams.put("preserveOriginal",
Integer.parseInt(luceneParams.get("preserveOriginal").toString()) == 1);
-}
-if (luceneParams.containsKey("splitOnNumerics")) {
-luceneParams.put("splitOnNumerics",
Integer.parseInt(luceneParams.get("splitOnNumerics").toString()) == 1);
-}
-if (luceneParams.containsKey("stemEnglishPossessive")) {
-luceneParams.put("stemEnglishPossessive",
Integer.parseInt(luceneParams.get("stemEnglishPossessive").toString()) == 1);
-}
+Consumer transformFlag = flag -> {
+if (luceneParams.containsKey(flag)) {
+luceneParams.put(flag,
Integer.parseInt(luceneParams.get(flag).toString()) == 1);
+}
Review Comment:
I think this can be done with
```
luceneParms.computeIfPresent(flag,
Integer.parseInt(luceneParams.get(flag).toString() == 1)
```
https://docs.oracle.com/en%2Fjava%2Fjavase%2F11%2Fdocs%2Fapi%2F%2F/java.base/java/util/Map.html#computeIfPresent(K,java.util.function.BiFunction)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danilo Banjac updated JCRVLT-753:
-
Description:
{*}Issue Description{*}:
Recent updates to the replication conflict resolution strategy in Adobe
Experience Manager (AEM) using JCR Filevault have led to failures when
attempting to replicate content packages. Specifically, the shift from the
*LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
*javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to the
attempted deletion of mandatory child nodes during the replication process.
{*}Steps to Reproduce{*}:
1. Create a content package with a primary node of type *nt:file* and a
mandatory child node {*}jcr:content{*}.
2. Update the version of the content package, ensuring the *jcr:uuid* of the
*jcr:content* node remains unchanged.
3. Replicate the updated content package.
{*}Observed Behavior{*}:
- The replication framework attempts to remove the conflicting *jcr:content*
node due to the identical {*}jcr:uuid{*}.
- The deletion operation fails because the parent *nt:file* node requires the
*jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
"{*}Mandatory child node jcr:content cannot be removed.{*}"
{*}Root Cause{*}:
The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not account
for the constraints of mandatory child nodes in the JCR repository, leading to
violations when trying to remove these nodes.
{*}Impact{*}:
This issue prevents successful replication of updated content packages in AEM,
disrupting content management workflows and generating errors in the log.
*Nodes Used for Testing*
{noformat}
{
"jcr:primaryType": "nt:file",
"jcr:createdBy": "sling-distribution-importer",
"jcr:created": "Tue May 14 2024 10:13:41 GMT+",
"jcr:content": {
"jcr:primaryType": "nt:resource",
"jcr:mixinTypes": [
"vlt:Package"
],
"jcr:lastModifiedBy": "admin",
"jcr:mimeType": "application/zip",
"jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
":jcr:data": 35146,
"jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
"vlt:definition": {
"jcr:primaryType": "vlt:PackageDefinition",
"testedWith": "",
"lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
"lastUnpackedBy": "sling-distribution-importer",
"requiresRestart": false,
"requiresRoot": false,
"lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
"buildCount": "17",
"providerLink": "",
"providerName": "",
"jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
"name": "global-truststore",
"group": "admin-tasks",
"version": "15.0",
"dependencies": [],
"fixedBugs": "",
"jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
"lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
"providerUrl": "",
"screenshots": {
"jcr:primaryType": "nt:unstructured"
},
"filter": {
"jcr:primaryType": "nt:unstructured",
"f0": {
"jcr:primaryType": "nt:unstructured",
"propertyRules": [],
"mode": "replace",
"root": "/etc/truststore",
"rules": []
}
}
}
}
}{noformat}
was:
AEM has a user synchronisation capability in the publish tier. The
synchronisation mechanism relies on FileVault to export and import content.
Users stored in the repository under a path that starts with a _ and that
contain another _ can be exported but fail to be re-imported. For instance, the
user stored under the path /home/users/test/_6k_test-user-a won't be imported.
Debugging this issue, it seems that FileVault treats the _6k_ pattern as a
namespace and thus skip the resource upon import because the paths don't match.
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary
Re: [PR] OAK-10788 - Indexing job downloader: shutdown gracefully all threads in case of failure [jackrabbit-oak]
nfsantos commented on code in PR #1456:
URL: https://github.com/apache/jackrabbit-oak/pull/1456#discussion_r1601044885
##
oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/flatfile/pipelined/PipelinedStrategy.java:
##
@@ -545,16 +540,32 @@ public File createSortedStoreFile() throws IOException {
indexingReporter.addTiming("Build FFS (Dump+Merge)",
FormattingUtils.formatToSeconds(elapsedSeconds));
LOG.info("[INDEXING_REPORT:BUILD_FFS]\n{}",
indexingReporter.generateReport());
-} catch (InterruptedException e) {
+} catch (Throwable e) {
+LOG.warn("Error dumping from MongoDB. Cancelling all tasks.
Error: {}", e.toString());
+// Cancel in order
+cancelFuture(downloadFuture);
+for (Future transformTask : transformFutures) {
+cancelFuture(transformTask);
+}
+cancelFuture(sortBatchFuture);
+cancelFuture(mergeSortFuture);
throw new RuntimeException(e);
} finally {
// No longer need to monitor the size of the queues,
monitorFuture.cancel(true);
}
return flatFileStore.toFile();
} finally {
-threadPool.shutdown();
-monitorThreadPool.shutdown();
+LOG.info("Shutting down build FFS thread pool");
+new ExecutorCloser(threadPool).close();
+monitorThreadPool.shutdownNow();
Review Comment:
It was a miss. I refactored the code so that the `monitorThreadPool` is no
longer needed. The periodic logging that was being done by this thread pool is
now done by the main thread, using a timeout on waiting for the other tasks to
finish. This reduces the amount of code and eliminates one thread pool, and is
also less brittle.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[ https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danilo Banjac updated JCRVLT-753: - Fix Version/s: (was: 3.7.4) > FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception > in AEM Replication > -- > > Key: JCRVLT-753 > URL: https://issues.apache.org/jira/browse/JCRVLT-753 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Danilo Banjac >Assignee: Konrad Windszus >Priority: Major > Labels: vault > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[ https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danilo Banjac updated JCRVLT-753: - Affects Version/s: (was: 3.7.2) > FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception > in AEM Replication > -- > > Key: JCRVLT-753 > URL: https://issues.apache.org/jira/browse/JCRVLT-753 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Danilo Banjac >Assignee: Konrad Windszus >Priority: Major > Labels: vault > Fix For: 3.7.4 > > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
Danilo Banjac created JCRVLT-753: Summary: FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication Key: JCRVLT-753 URL: https://issues.apache.org/jira/browse/JCRVLT-753 Project: Jackrabbit FileVault Issue Type: Bug Components: vlt Affects Versions: 3.7.2 Reporter: Danilo Banjac Assignee: Konrad Windszus Fix For: 3.7.4 AEM has a user synchronisation capability in the publish tier. The synchronisation mechanism relies on FileVault to export and import content. Users stored in the repository under a path that starts with a _ and that contain another _ can be exported but fail to be re-imported. For instance, the user stored under the path /home/users/test/_6k_test-user-a won't be imported. Debugging this issue, it seems that FileVault treats the _6k_ pattern as a namespace and thus skip the resource upon import because the paths don't match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Jackrabbit Filevault 3.7.4 Release Plan
On 14.05.2024 16:00, Julian Reschke wrote: Hi, I'm planning to cut Jackrabbit Filevault 3.7.4 on Thursday. The list of open issues scheduled for 3.7.4 is: https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%203.7.4%20AND%20project%20%3D%20JCRVLT%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC I plan to re-schedule these for 3.7.6. If there are any objections please let me know. Best regards, Julian Ok, I have moved the unresolved issues to 3.7.6. Candidate Release Notes are over here: https://github.com/apache/jackrabbit-filevault/commit/22b01b3817be8d6c055427697d824924a6f58ff9 I will start the release process tomorrow. Best regards, Julian
[jira] [Updated] (JCRVLT-659) Warn for different prefixes used in FileVault XML and importing repo
[ https://issues.apache.org/jira/browse/JCRVLT-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-659: -- Fix Version/s: 3.7.6 (was: 3.7.4) > Warn for different prefixes used in FileVault XML and importing repo > > > Key: JCRVLT-659 > URL: https://issues.apache.org/jira/browse/JCRVLT-659 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.7.6 > > > Due to the reasons outlined at > https://jackrabbit.apache.org/filevault/nodetypes.html#namespace-prefixes > different namespace mappings (i.e. other prefixes for used namespace URIs) > may lead to subtle issues and should therefore always lead to a WARN during > import. > Maybe one should even fail the installation in Strict mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-716) Prevent duplicate validation issues for subpackage validation
[ https://issues.apache.org/jira/browse/JCRVLT-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-716: -- Fix Version/s: 3.7.6 (was: 3.7.4) > Prevent duplicate validation issues for subpackage validation > - > > Key: JCRVLT-716 > URL: https://issues.apache.org/jira/browse/JCRVLT-716 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: validation >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.6 > > > Often a validator is called twice on the same package: > * In the context of a standalone package (triggered from a non-container > Maven module) > * In the context as subpackage inside a container module > Currently lots of validators emit duplicate reports and also settings often > needs to be copied over to the container package. > Therefore with default settings validators should prevent emitting issues > twice but preferably only in the first context. The second context should > only emit issues which cannot be detected for the standalone case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-619) Allow to define node types per validRoot and leverage it from validator: jackrabbit-nodetype
[ https://issues.apache.org/jira/browse/JCRVLT-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-619: -- Fix Version/s: 3.7.6 (was: 3.7.4) > Allow to define node types per validRoot and leverage it from validator: > jackrabbit-nodetype > > > Key: JCRVLT-619 > URL: https://issues.apache.org/jira/browse/JCRVLT-619 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Reporter: Konrad Windszus >Priority: Major > Fix For: 3.7.6 > > > It would be good to allow to define it in an external Maven artifact so that > these definitions could be provided per distribution/version. Also it should > be possible to allow definitions which are derived from some other metadata > (like [Sling Repo Init > statements|https://sling.apache.org/documentation/bundles/repository-initialization.html]). > Both means should be allowed at the same time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-523) Expose subpackages from RegisteredPackage
[ https://issues.apache.org/jira/browse/JCRVLT-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCRVLT-523: -- Fix Version/s: 3.7.6 (was: 3.7.4) > Expose subpackages from RegisteredPackage > - > > Key: JCRVLT-523 > URL: https://issues.apache.org/jira/browse/JCRVLT-523 > Project: Jackrabbit FileVault > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.6 > > > There should be a method which exposes all direct subpackages of an existing > package. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-524) JcrPackageRegistry.register should always register the subpackages as well
[
https://issues.apache.org/jira/browse/JCRVLT-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCRVLT-524:
--
Fix Version/s: 3.7.6
(was: 3.7.4)
> JcrPackageRegistry.register should always register the subpackages as well
> --
>
> Key: JCRVLT-524
> URL: https://issues.apache.org/jira/browse/JCRVLT-524
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.7.6
>
>
> The {{FSPackageRegistry}} already registers all contained subpackages with a
> call to {{PackageRegistry.register(...)}}
> (https://github.com/apache/jackrabbit-filevault/blob/14615ce5647252005f2271b5f5f0351eb91aa78e/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L362)
> both for internal and external files, while
> {{JcrPackageRegistry.register(...)}} does not do that
> (https://github.com/apache/jackrabbit-filevault/blob/14615ce5647252005f2271b5f5f0351eb91aa78e/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/JcrPackageRegistry.java#L348).
> The handling should be consolidated so that all implementations always
> register also the contained subpackages and the javadoc of
> {{PackageRegistry.register(...)}} clarified accordingly.
> Registering subpackages probably requires extracting them from the container
> package and store as dedicated package which leads to increased memory
> consumption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-522) Authorizable and authorization nodes applied even if filter rules exclude them
[
https://issues.apache.org/jira/browse/JCRVLT-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCRVLT-522:
--
Fix Version/s: 3.7.6
(was: 3.7.4)
> Authorizable and authorization nodes applied even if filter rules exclude them
> --
>
> Key: JCRVLT-522
> URL: https://issues.apache.org/jira/browse/JCRVLT-522
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.4.10
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.6
>
>
> Currently the filter rules are not fully evaluated prior to applying ACLs (in
> rep:policy and rep:repoPolicy files). According to JCRVLT-372 this is a bug.
> The same is true for authorizable nodes (compare with JCRVLT-71).
> The exact install behaviour is as follows (given that the ACHandling is not
> IGNORE):
>
> || ||ACL Path in Filter?||Effect||Example ACL Path(s)||Example Content Node
> Path(s)||
> ||1|Contained in
> filter|Installed|/testroot/node_a/rep:policy|/testroot/node_a||
> ||2|Not contained in filter, but ancestor is
> contained|Installed|/testroot/secured/rep:policy|testroot/secured||
> ||3|Neither path nor ancestor is contained in filter|Not
> Installed|/test2/rep:policy|/test2||
> ||4|Path is not contained in filter, ancestor is not contained either, but
> node affected by ACLs is contained|Not
> Installed|/testroot/rep:policy|/testroot||
> The example columns assume the following filter.xml
> {code}
>
>
>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-752) Release Jackrabbit Filevault 3.7.4
Julian Reschke created JCRVLT-752: - Summary: Release Jackrabbit Filevault 3.7.4 Key: JCRVLT-752 URL: https://issues.apache.org/jira/browse/JCRVLT-752 Project: Jackrabbit FileVault Issue Type: Task Reporter: Julian Reschke Assignee: Julian Reschke -- This message was sent by Atlassian Jira (v8.20.10#820010)
