Re: [PR] OAK-10739 : revert unrelated or unnecessary changes [jackrabbit-oak]

2024-05-16 Thread via GitHub


stefan-egli merged PR #1467:
URL: https://github.com/apache/jackrabbit-oak/pull/1467


-- 
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 : revert unrelated or unnecessary changes [jackrabbit-oak]

2024-05-16 Thread via GitHub


stefan-egli opened a new pull request, #1467:
URL: https://github.com/apache/jackrabbit-oak/pull/1467

   (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-10812: DocumentNodeStore#diffManyChildren(...) may produce incorr… [jackrabbit-oak]

2024-05-16 Thread via GitHub


stefan-egli commented on PR #1465:
URL: https://github.com/apache/jackrabbit-oak/pull/1465#issuecomment-2115770736

   I'm wondering if that wouldn't introduce a regression elsewhere .. there 
must have been a reason this was set to 0 for read-only?


-- 
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-10812: DocumentNodeStore#diffManyChildren(...) may produce incorr… [jackrabbit-oak]

2024-05-16 Thread via GitHub


mbaedke commented on PR #1465:
URL: https://github.com/apache/jackrabbit-oak/pull/1465#issuecomment-2115695591

   Potential fix: if in DocumentNodeStore#getMinExternalRevisions() we replace 
getClusterId() - which is 0 in readonly mode - with the configured cluster id, 
the problem disappears.


-- 
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-10812: DocumentNodeStore#diffManyChildren(...) may produce incorr… [jackrabbit-oak]

2024-05-16 Thread via GitHub


mbaedke commented on PR #1465:
URL: https://github.com/apache/jackrabbit-oak/pull/1465#issuecomment-2115387932

   Preliminary test. Please review if it makes any sense.


-- 
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-10812: DocumentNodeStore#diffManyChildren(...) may produce incorr… [jackrabbit-oak]

2024-05-16 Thread via GitHub


mbaedke opened a new pull request, #1465:
URL: https://github.com/apache/jackrabbit-oak/pull/1465

   …ect results in readonly mode
   
   Added test case.


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

2024-05-16 Thread via GitHub


nfsantos merged PR #1461:
URL: https://github.com/apache/jackrabbit-oak/pull/1461


-- 
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 : Provide support for FullGC in Mongo DocumentStore [jackrabbit-oak]

2024-05-16 Thread via GitHub


stefan-egli commented on code in PR #1454:
URL: https://github.com/apache/jackrabbit-oak/pull/1454#discussion_r1603281901


##
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:
   it seems to be a preexisting issue though, unrelated to fullGC? I'd prefer 
to remove it.



-- 
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-10810 - Remove redundant call to StringCache.get in Path.fromString. [jackrabbit-oak]

2024-05-16 Thread via GitHub


nfsantos merged PR #1464:
URL: https://github.com/apache/jackrabbit-oak/pull/1464


-- 
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-10810 - Remove redundant call to StringCache.get in Path.fromString. [jackrabbit-oak]

2024-05-16 Thread via GitHub


nfsantos opened a new pull request, #1464:
URL: https://github.com/apache/jackrabbit-oak/pull/1464

   (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



[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore

2024-05-16 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846886#comment-17846886
 ] 

Julian Reschke commented on JCRVLT-754:
---

For the basenames, can we switch it for filevault maintenance releases as well, 
or would it better just to support both (by inspecting the release folder)?

> 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
>Assignee: Konrad Windszus
>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)


[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore

2024-05-16 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846885#comment-17846885
 ] 

Julian Reschke commented on JCRVLT-754:
---

Yes. So for the SHA1, the options appear to be:

- do not use it (put the SHA256 into the vote template)m or
- compute it on demand in check-release.

The latter would be something like:

{noformat}
@@ -175,6 +175,14 @@
 SHA_OK=true
   fi
 done
+if [ $SHA_OK != 0 ]; then
+  # compute SHA1 of artefact and compare that
+  EXPECTED_SHA1="`openssl "sha1" "$BASEDIR/$RCDIR/$NAME" 2>> "$LOGFILE" | sed 
's/.*= *//'`"
+  if [ $EXPECTED_SHA1 = $SHA ]; then
+info "   (using computed SHA1 of $BASEDIR/$RCDIR/$NAME for SHA argument 
comparison)"
+SHA_OK=true
+  fi
+fi
 if $SHA_OK; then
 info "   OK: $SHA"
{noformat}


> 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
>Assignee: Konrad Windszus
>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)


[jira] [Comment Edited] (JCRVLT-754) check-release does not work for filevault anymore

2024-05-16 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846885#comment-17846885
 ] 

Julian Reschke edited comment on JCRVLT-754 at 5/16/24 9:12 AM:


Yes. So for the SHA1, the options appear to be:

- do not use it (put the SHA256 into the vote template) or
- compute it on demand in check-release.

The latter would be something like:

{noformat}
@@ -175,6 +175,14 @@
 SHA_OK=true
   fi
 done
+if [ $SHA_OK != 0 ]; then
+  # compute SHA1 of artefact and compare that
+  EXPECTED_SHA1="`openssl "sha1" "$BASEDIR/$RCDIR/$NAME" 2>> "$LOGFILE" | sed 
's/.*= *//'`"
+  if [ $EXPECTED_SHA1 = $SHA ]; then
+info "   (using computed SHA1 of $BASEDIR/$RCDIR/$NAME for SHA argument 
comparison)"
+SHA_OK=true
+  fi
+fi
 if $SHA_OK; then
 info "   OK: $SHA"
{noformat}



was (Author: reschke):
Yes. So for the SHA1, the options appear to be:

- do not use it (put the SHA256 into the vote template)m or
- compute it on demand in check-release.

The latter would be something like:

{noformat}
@@ -175,6 +175,14 @@
 SHA_OK=true
   fi
 done
+if [ $SHA_OK != 0 ]; then
+  # compute SHA1 of artefact and compare that
+  EXPECTED_SHA1="`openssl "sha1" "$BASEDIR/$RCDIR/$NAME" 2>> "$LOGFILE" | sed 
's/.*= *//'`"
+  if [ $EXPECTED_SHA1 = $SHA ]; then
+info "   (using computed SHA1 of $BASEDIR/$RCDIR/$NAME for SHA argument 
comparison)"
+SHA_OK=true
+  fi
+fi
 if $SHA_OK; then
 info "   OK: $SHA"
{noformat}


> 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
>Assignee: Konrad Windszus
>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: [PR] OAK-10780: add azure access token refresh logic [jackrabbit-oak]

2024-05-16 Thread via GitHub


rootpea commented on code in PR #1441:
URL: https://github.com/apache/jackrabbit-oak/pull/1441#discussion_r1602892162


##
oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/AzureUtilities.java:
##
@@ -207,6 +230,61 @@ public void write(@NotNull byte[] bytes, int offset, int 
length) {
 }
 }
 
+/**
+ * This class represents a token refresher responsible for ensuring the 
validity of the access token used for azure AD authentication.
+ * The access token generated by the Azure client is valid for 1 hour 
only. Therefore, this class periodically checks the validity
+ * of the access token and refreshes it if necessary. The refresh is 
triggered when the current access token is about to expire,
+ * defined by a threshold of 5 minutes from the current time. This 
threshold is similar to what is being used in azure identity to
+ * generate a new token
+ */
+private static class TokenRefresher implements Runnable {
+
+private final ClientSecretCredential clientSecretCredential;
+private AccessToken accessToken;
+private final StorageCredentialsToken storageCredentialsToken;
+
+
+/**
+ * Constructs a new TokenRefresher object with the specified 
parameters.
+ *
+ * @param clientSecretCredential  The client secret credential used to 
obtain the access token.
+ * @param accessToken The current access token.
+ * @param storageCredentialsToken The storage credentials token 
associated with the access token.
+ */
+public TokenRefresher(ClientSecretCredential clientSecretCredential,
+  AccessToken accessToken,
+  StorageCredentialsToken storageCredentialsToken) 
{
+this.clientSecretCredential = clientSecretCredential;
+this.accessToken = accessToken;
+this.storageCredentialsToken = storageCredentialsToken;
+}
+
+@Override
+public void run() {
+try {
+log.debug("Checking for azure access token expiry at: {}", 
LocalDateTime.now());
+OffsetDateTime tokenExpiryThreshold = 
OffsetDateTime.now().plusMinutes(5);
+if (accessToken.getExpiresAt() != null && 
accessToken.getExpiresAt().isBefore(tokenExpiryThreshold)) {
+log.info("Access token is about to expire (5 minutes or 
less) at: {}. New access token will be generated",

Review Comment:
   ```suggestion
   log.info("Access token is about to expire (20 minutes or 
less) at: {}. New access token will be generated",
   ```



-- 
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-10780: add azure access token refresh logic [jackrabbit-oak]

2024-05-16 Thread via GitHub


rootpea commented on code in PR #1441:
URL: https://github.com/apache/jackrabbit-oak/pull/1441#discussion_r1602891748


##
oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/AzureUtilities.java:
##
@@ -207,6 +230,61 @@ public void write(@NotNull byte[] bytes, int offset, int 
length) {
 }
 }
 
+/**
+ * This class represents a token refresher responsible for ensuring the 
validity of the access token used for azure AD authentication.
+ * The access token generated by the Azure client is valid for 1 hour 
only. Therefore, this class periodically checks the validity
+ * of the access token and refreshes it if necessary. The refresh is 
triggered when the current access token is about to expire,
+ * defined by a threshold of 5 minutes from the current time. This 
threshold is similar to what is being used in azure identity to
+ * generate a new token
+ */
+private static class TokenRefresher implements Runnable {
+
+private final ClientSecretCredential clientSecretCredential;
+private AccessToken accessToken;
+private final StorageCredentialsToken storageCredentialsToken;
+
+
+/**
+ * Constructs a new TokenRefresher object with the specified 
parameters.
+ *
+ * @param clientSecretCredential  The client secret credential used to 
obtain the access token.
+ * @param accessToken The current access token.
+ * @param storageCredentialsToken The storage credentials token 
associated with the access token.
+ */
+public TokenRefresher(ClientSecretCredential clientSecretCredential,
+  AccessToken accessToken,
+  StorageCredentialsToken storageCredentialsToken) 
{
+this.clientSecretCredential = clientSecretCredential;
+this.accessToken = accessToken;
+this.storageCredentialsToken = storageCredentialsToken;
+}
+
+@Override
+public void run() {
+try {
+log.debug("Checking for azure access token expiry at: {}", 
LocalDateTime.now());
+OffsetDateTime tokenExpiryThreshold = 
OffsetDateTime.now().plusMinutes(5);

Review Comment:
   ```suggestion
   OffsetDateTime tokenExpiryThreshold = 
OffsetDateTime.now().plusMinutes(20);
   ```



-- 
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-10808 - Skip test if Mongo is not available. [jackrabbit-oak]

2024-05-16 Thread via GitHub


nfsantos merged PR #1463:
URL: https://github.com/apache/jackrabbit-oak/pull/1463


-- 
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-754) check-release does not work for filevault anymore

2024-05-16 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846855#comment-17846855
 ] 

Konrad Windszus commented on JCRVLT-754:


bq. no sha1 is generated anymore; however, this is what is put into the 
generated vote template.

The SHA1 is generated, but no longer persisted. It is used in the email 
template: 
https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300

> 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
>Assignee: Konrad Windszus
>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)


[jira] [Commented] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant

2024-05-16 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846854#comment-17846854
 ] 

Konrad Windszus commented on JCRVLT-742:


FTR: The SHA1 is still generated and used in the email template being 
generated, but no longer persisted as file: 
https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300

> Stop generating MD5, SHA1 and SHA512 with Ant
> -
>
> Key: JCRVLT-742
> URL: https://issues.apache.org/jira/browse/JCRVLT-742
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4, package-maven-plugin-1.3.8
>
>
> Currently there is still manual generation of MD5, SHA1 and SHA512 checksum 
> via Ant in 
> https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
>  and 
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.
> MD5 and SHA1 should no longer be provided according to 
> https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 
> is automatically created through the ASF parent pom 
> (https://maven.apache.org/pom/asf/#the-apache-release-profile).
> In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the 
> SHA512 anyways.
> Note: This is only about ASF dist not about the checksums used in Maven 
> repositories which are transparently created by Maven Resolver.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Assigned] (JCRVLT-754) check-release does not work for filevault anymore

2024-05-16 Thread Konrad Windszus (Jira)


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

Konrad Windszus reassigned JCRVLT-754:
--

Assignee: Konrad Windszus

> 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
>Assignee: Konrad Windszus
>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)


[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication

2024-05-16 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846849#comment-17846849
 ] 

Konrad Windszus commented on JCRVLT-753:


We should at least clarify the javadoc of 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html
 to make it clear that {{FORCE_REMOVE_CONFLICTING_ID}} may lead to exceptions 
as well.

> 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-10804 - Optimize check for hidden paths and clear warnings in NodeStateUtils class. [jackrabbit-oak]

2024-05-16 Thread via GitHub


nfsantos commented on code in PR #1461:
URL: https://github.com/apache/jackrabbit-oak/pull/1461#discussion_r1602707774


##
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:
   Good point. But the check in `PathUtils.elements(path)` is done by an 
`assert`. And very likely asserts will be disabled in production (the default 
in the JVM is disabled). And in any case, it is bad practice to rely on asserts 
in production. So I think it is ok to change the behavior.



-- 
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-10808 - Skip test if Mongo is not available. [jackrabbit-oak]

2024-05-16 Thread via GitHub


nfsantos opened a new pull request, #1463:
URL: https://github.com/apache/jackrabbit-oak/pull/1463

   (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



[jira] [Created] (JCR-5062) Attempt to return connection twice

2024-05-16 Thread Jira
Henrik Hald Nørgaard created JCR-5062:
-

 Summary: Attempt to return connection twice
 Key: JCR-5062
 URL: https://issues.apache.org/jira/browse/JCR-5062
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.20.16
Reporter: Henrik Hald Nørgaard
 Attachments: stacktrace.txt

We are using a JackRabbit content repository and are going to update some nodes 
with a new mixin. While iterating through the nodes that should be updated, the 
following warning sometimes appears in the log:

{{WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] 
(ServerService Thread Pool -- 88) IJ000609: Attempt to return connection twice: 
org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener@f6ff104[state=NORMAL
 managed 
connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@7f3ceaf7 
connection handles=0 lastReturned=1715156332529 lastValidated=1715156332529 
lastCheckedOut=1715156332528 trackByTx=false 
pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@16cc91e8 
mcp=SemaphoreConcurrentLinkedQueueManagedConnectionPool@53f6d09[pool=DezideAuthorJackrabbit]]:
 java.lang.Throwable: STACKTRACE}}

I have attached a stacktrace.

It seems that the database connection handled by the BundleDbPersistenceManager 
can in some situations be closed twice?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)