[GitHub] [jackrabbit-oak] mreutegg closed pull request #346: OAK-9535 : support/fix recovery of large branch merge that could breach the 16MB document size restriction on MongoDB
mreutegg closed pull request #346: URL: https://github.com/apache/jackrabbit-oak/pull/346 -- 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
[GitHub] [jackrabbit-oak] mreutegg commented on pull request #346: OAK-9535 : support/fix recovery of large branch merge that could breach the 16MB document size restriction on MongoDB
mreutegg commented on pull request #346: URL: https://github.com/apache/jackrabbit-oak/pull/346#issuecomment-908945307 PR #354 supersedes this. -- 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
[GitHub] [jackrabbit-oak] mreutegg merged pull request #354: OAK-9535: Support recovery of large branch merge
mreutegg merged pull request #354: URL: https://github.com/apache/jackrabbit-oak/pull/354 -- 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
[GitHub] [jackrabbit-filevault] tripodsan edited a comment on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
tripodsan edited a comment on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908923335 > Look at the test case: It leads to some ACLs being applied although outside the filter, because no subsequent filtering happens. Bug or Feature? I would say, if the effective ACL on one of the items included in the filter is affected, then the ACL should be applied. i.e. in general, all ACLs not included in the filter *but* that are ancestors of the filtered items should be applied. all ACLs that are not covered in the filter and do not affect the items in the covered tree should not be modified. -- 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
[GitHub] [jackrabbit-filevault] tripodsan commented on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
tripodsan commented on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908923335 > Look at the test case: It leads to some ACLs being applied although outside the filter, because no subsequent filtering happens. Bug or Feature? I would say, if the effective ACL on one of the items included in the filter is affected, then the ACL should be applied. i.e. in general, all ACLs not included in the filter *but* that are ancestors of the filtered items should be applied. all ACLs that do not affect the items in the covered tree should not be modified. -- 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-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 ] Konrad Windszus updated JCRVLT-522: --- Description: 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: || ||Path||Effect|| ||1|Contained in filter|Installed| ||2|Not contained in filter, but ancestor is contained|Installed| ||3|Neither path nor ancestor is contained|Not Installed| was:Currently the filter rules are not 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). > 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.5.4 > > > 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: > || ||Path||Effect|| > ||1|Contained in filter|Installed| > ||2|Not contained in filter, but ancestor is contained|Installed| > ||3|Neither path nor ancestor is contained|Not Installed| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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 ] Konrad Windszus updated JCRVLT-522: --- Description: 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: || ||Path in Filter?||Effect|| ||1|Contained in filter|Installed| ||2|Not contained in filter, but ancestor is contained|Installed| ||3|Neither path nor ancestor is contained in filter|Not Installed| was: 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: || ||Path||Effect|| ||1|Contained in filter|Installed| ||2|Not contained in filter, but ancestor is contained|Installed| ||3|Neither path nor ancestor is contained|Not Installed| > 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.5.4 > > > 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: > || ||Path in Filter?||Effect|| > ||1|Contained in filter|Installed| > ||2|Not contained in filter, but ancestor is contained|Installed| > ||3|Neither path nor ancestor is contained in filter|Not Installed| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [jackrabbit-filevault] kwin commented on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
kwin commented on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908632407 Look at the test case: It leads to some ACLs being applied although outside the filter, because no subsequent filtering happens. Bug or Feature? -- 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
[GitHub] [jackrabbit-filevault] tripodsan commented on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
tripodsan commented on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908628029 > @tripodsan In general filter rules seem to be followed except for one edge case. What is the idea of `Importer.postFilter` ( > > https://github.com/apache/jackrabbit-filevault/blob/61e920f55e487aa5dc045c66ce5b7b5e444784ca/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Importer.java#L518 > > )? Is that supposed to filter out everything on an artifact level not contained in a filter and the DocViewSAXImporter only does the filtering on sub artifact level? I think it is used to find the TXInfo hierarchy that is covered by the filter maybe :-) > If so do you consider Importer.postFilter errorneous as it does not correctly filter out artifacts which are below a contained node (but excluded)? I don't think this will lead to errors. AFAIR, this is only the preliminary scan. the nodes are filtered again when traversing. but I might be wrong. it was a long time ago, when this code was created :-) -- 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
[GitHub] [jackrabbit-filevault] kwin edited a comment on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
kwin edited a comment on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908214373 @tripodsan In general filter rules seem to be followed except for one edge case. What is the idea of `Importer.postFilter` (https://github.com/apache/jackrabbit-filevault/blob/61e920f55e487aa5dc045c66ce5b7b5e444784ca/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Importer.java#L518)? Is that supposed to filter out everything on an artifact level not contained in a filter and the DocViewSAXImporter only does the filtering on sub artifact level? If so do you consider Importer.postFilter errorneous as it does not correctly filter out artifacts which are below a contained node (but excluded)? -- 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
[GitHub] [jackrabbit-filevault] kwin commented on pull request #163: JCRVLT-549 - node cannot be deleted if it's a multi-mandatory child node
kwin commented on pull request #163: URL: https://github.com/apache/jackrabbit-filevault/pull/163#issuecomment-908595813 Please add a failing test which succeeds with this patch. -- 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-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406886#comment-17406886
]
Dominik Süß commented on JCRVLT-391:
[~kwin] this is based on our baseline chels we perform to prevent adopting
breaking changes without validation of the impact. So the breaking change
happened in a differ Commit- thx for the pointer. This helps me to verify /
proof that noone is depending on the removed api. ( i know it’s very unlikely
but we‘ve seen the weirdest abuse of internal utils already )
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [jackrabbit-filevault] tripodsan commented on a change in pull request #163: JCRVLT-549 - node cannot be deleted if it's a multi-mandatory child node
tripodsan commented on a change in pull request #163:
URL:
https://github.com/apache/jackrabbit-filevault/pull/163#discussion_r698665828
##
File path:
vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java
##
@@ -1215,13 +1215,13 @@ public void endElement(String uri, String localName,
String qName) throws SAXExc
}
} else {
if (wspFilter.getImportMode(path) ==
ImportMode.REPLACE) {
-importInfo.onDeleted(path);
// check if child is not protected
if (child.getDefinition().isProtected()) {
log.debug("Refuse to delete protected
child node: {}", path);
-} else if
(child.getDefinition().isMandatory()) {
+} else if (child.getDefinition().isMandatory()
&& numChildren <= JcrConstants.NUM_MANDATORY_CHILDREN) {
Review comment:
however, I think this check is not correct. you need to count the number
of child nodes that match the property definition. just having any other child
node is not enough.
--
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
[GitHub] [jackrabbit-filevault] tripodsan commented on a change in pull request #163: JCRVLT-549 - node cannot be deleted if it's a multi-mandatory child node
tripodsan commented on a change in pull request #163:
URL:
https://github.com/apache/jackrabbit-filevault/pull/163#discussion_r698664688
##
File path:
vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java
##
@@ -1215,13 +1215,13 @@ public void endElement(String uri, String localName,
String qName) throws SAXExc
}
} else {
if (wspFilter.getImportMode(path) ==
ImportMode.REPLACE) {
-importInfo.onDeleted(path);
Review comment:
why did you remove this?
--
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
[GitHub] [jackrabbit-filevault] tripodsan commented on a change in pull request #163: JCRVLT-549 - node cannot be deleted if it's a multi-mandatory child node
tripodsan commented on a change in pull request #163:
URL:
https://github.com/apache/jackrabbit-filevault/pull/163#discussion_r698664333
##
File path:
vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java
##
@@ -1215,13 +1215,13 @@ public void endElement(String uri, String localName,
String qName) throws SAXExc
}
} else {
if (wspFilter.getImportMode(path) ==
ImportMode.REPLACE) {
-importInfo.onDeleted(path);
// check if child is not protected
if (child.getDefinition().isProtected()) {
log.debug("Refuse to delete protected
child node: {}", path);
-} else if
(child.getDefinition().isMandatory()) {
+} else if (child.getDefinition().isMandatory()
&& numChildren <= JcrConstants.NUM_MANDATORY_CHILDREN) {
Review comment:
I don't think that this requires a constant.
```suggestion
} else if
(child.getDefinition().isMandatory() && numChildren <= 1) {
```
--
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-549) node cannot be deleted if it's a multi-mandatory child node
[
https://issues.apache.org/jira/browse/JCRVLT-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406832#comment-17406832
]
Ankita Agarwal commented on JCRVLT-549:
---
[~kwin]/ [~tripod] Raised a PR
https://github.com/apache/jackrabbit-filevault/pull/163
Request you to review the PR.
> node cannot be deleted if it's a multi-mandatory child node
> ---
>
> Key: JCRVLT-549
> URL: https://issues.apache.org/jira/browse/JCRVLT-549
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Ankita Agarwal
>Priority: Major
> Fix For: 3.5.4
>
>
> Let say we have a rule in nodetype.cnd file
> {code:xml}
> [a:RolloutConfig] > mix:title
> orderable
> - a:trigger (string) mandatory
> + * (a:LiveSyncAction) mandatory
> [a:LiveSyncAction] > nt:unstructured
> {code}
> When a package(first) is installed where parent node's(rolloutconfigs)
> .content.xml has:
> {code:xml}
>
> http://sling.apache.org/jcr/sling/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0"; xmlns:rep="internal"
> jcr:mixinTypes="[rep:AccessControllable]"
> jcr:primaryType="sling:OrderedFolder"
> jcr:title="Rollout Configurations">
>
>
>
>
>
> {code}
> and default node's has .content.xml
> {code:xml}
>
> http://www.day.com/jcr/a/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0";
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
>
>
>
> {code}
> Installing another package(second) with the same cnd file but with different
> child node's(default node) content.xml:
> {code:xml}
>
> http://www.day.com/jcr/a/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0";
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
> {code}
> marks the below node for Deletion but doesn't delete them because it's a
> mandatory node
> {code:xml}
> D /x/y/z/rolloutconfigs/default/contentDelete
> D /x/y/z/rolloutconfigs/default/contentUpdate
> D /x/y/z/rolloutconfigs/default/orderChildren
> D /x/y/z/rolloutconfigs/default/personalizationContentRollout
> D /x/y/z/rolloutconfigs/default/referencesUpdate
> {code}
> The issue lies at
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1190
> . Here, check for the child node is mandatory or not is done after marking
> it for delete importInfo.onDeleted(path) which gives wrong information that
> the child node is deleted but in the repository, it still exists.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406812#comment-17406812
]
Konrad Windszus edited comment on JCRVLT-391 at 8/30/21, 4:22 PM:
--
{{org.apache.jackrabbit.vault.util.xml.serialize}} has been increased to 3.0.0
because formerly public classes have been removed
(https://github.com/apache/jackrabbit-filevault/commit/ffe8e36fbdb3023a4436b820463197762aa9c281#diff-98491387af99e0595ce4f42692221e831a038d9f94bf6b3316383336eae20378L1).
{{org.apache.jackrabbit.vault.util.xml}} does not contain any classes,
therefore the package version should not matter (there should never be a
import-package towards it). But maybe in the past it contained some classes. We
can remove the package-version there (and by that no longer export that empty
package).
What concrete issue do you have? Which bundle has conflicting imports to those
packages?
was (Author: kwin):
{{org.apache.jackrabbit.vault.util.xml.serialize}} has been increased to 3.0.0
because formerly public classes have been removed
(https://github.com/apache/jackrabbit-filevault/commit/ffe8e36fbdb3023a4436b820463197762aa9c281#diff-98491387af99e0595ce4f42692221e831a038d9f94bf6b3316383336eae20378L1).
{{org.apache.jackrabbit.vault.util.xml}} does not contain any classes,
therefore the package version should not matter (there should never be a
import-package towards it). But maybe in the past it contained some classes. We
can remove the package-version there.
What concrete issue do you have? Which bundle has conflicting imports to those
packages?
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406812#comment-17406812
]
Konrad Windszus commented on JCRVLT-391:
{{org.apache.jackrabbit.vault.util.xml.serialize}} has been increased to 3.0.0
because formerly public classes have been removed
(https://github.com/apache/jackrabbit-filevault/commit/ffe8e36fbdb3023a4436b820463197762aa9c281#diff-98491387af99e0595ce4f42692221e831a038d9f94bf6b3316383336eae20378L1).
{{org.apache.jackrabbit.vault.util.xml}} does not contain any classes,
therefore the package version should not matter (there should never be a
import-package towards it). But maybe in the past it contained some classes. We
can remove the package-version there.
What concrete issue do you have? Which bundle has conflicting imports to those
packages?
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCRVLT-391) Remove copied classes of Xerces
[
https://issues.apache.org/jira/browse/JCRVLT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406792#comment-17406792
]
Dominik Süß commented on JCRVLT-391:
[~kwin] - as I'm currently in the process of tracking down any kind of
potentially breaking dependencies for the version increase I stumbled over the
version increases of
https://github.com/apache/jackrabbit-filevault/commit/0b5716a2ffd3390731d7a3949e00dccf2e37b29a
specifically
{code}org.apache.jackrabbit.vault.util.xml
org.apache.jackrabbit.vault.util.xml.serialize
{code}
both receiving a major version increase although it looks like nothing has
changed for both packages.
Can you please shed some light on why a version increase was required or if
this was an accidential increase because of the refactoring efforts? If yes
could we please export the old version as well to not have dependencies
unnecessarily be detected as unsatisfied.
> Remove copied classes of Xerces
> ---
>
> Key: JCRVLT-391
> URL: https://issues.apache.org/jira/browse/JCRVLT-391
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.2
>
>
> Currently the classes below {{o.a.j.v.util.xml}} seem to be a copy of Xerces
> classes. Instead of just relying on an old copy one should use a proper Maven
> dependency together with https://maven.apache.org/plugins/maven-shade-plugin/
> or https://bnd.bndtools.org/instructions/conditionalpackage.html to make sure
> update to the latest version is possible.
> Also it needs to be clarified if the embedded Xerces should be listed
> explicitly in
> https://github.com/apache/jackrabbit-filevault/blob/trunk/LICENSE.txt.
> The original intent is stated in
> https://github.com/apache/jackrabbit-filevault/blob/9fa6c72bf4bdf36331b50b9370f3ed826a4622e8/vault-core/src/main/java/org/apache/jackrabbit/vault/util/xml/serialize/XMLSerializer.java#L64.
> The only modifications to the original Xerces were linebreaks after
> attributes and an alphabetic attribute sort order.
> The following alternatives are available:
> # Use the {{javax.xml.transform}} API (JAXP Transformation API, TrAX). There
> is no official way though to control the order of attribute, therefore I
> would recommend to already emit the attributes in the correct order instead
> of reordering them with the output. Controlling the indentation of
> attributes is hard to achieve:
> https://stackoverflow.com/questions/8393370/use-xslt-to-add-newlines-after-attributes
> # Use StAX with the Woodstox implementation. Seems faster, but still no
> sophisticated output formatting options available (like indentation options
> and line length)
> # Implement a simple serializer based on SAX events from scratch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [jackrabbit-oak] mreutegg commented on pull request #354: OAK-9535: Support recovery of large branch merge
mreutegg commented on pull request #354: URL: https://github.com/apache/jackrabbit-oak/pull/354#issuecomment-908402910 Rebased and squashed all commits by @stefan-egli and @mreutegg -- 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-549) node cannot be deleted if it's a multi-mandatory child node
[
https://issues.apache.org/jira/browse/JCRVLT-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406760#comment-17406760
]
Ankita Agarwal commented on JCRVLT-549:
---
[~kwin] I will provide the patch within this week.
> node cannot be deleted if it's a multi-mandatory child node
> ---
>
> Key: JCRVLT-549
> URL: https://issues.apache.org/jira/browse/JCRVLT-549
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.4.0
>Reporter: Ankita Agarwal
>Priority: Major
> Fix For: 3.5.4
>
>
> Let say we have a rule in nodetype.cnd file
> {code:xml}
> [a:RolloutConfig] > mix:title
> orderable
> - a:trigger (string) mandatory
> + * (a:LiveSyncAction) mandatory
> [a:LiveSyncAction] > nt:unstructured
> {code}
> When a package(first) is installed where parent node's(rolloutconfigs)
> .content.xml has:
> {code:xml}
>
> http://sling.apache.org/jcr/sling/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0"; xmlns:rep="internal"
> jcr:mixinTypes="[rep:AccessControllable]"
> jcr:primaryType="sling:OrderedFolder"
> jcr:title="Rollout Configurations">
>
>
>
>
>
> {code}
> and default node's has .content.xml
> {code:xml}
>
> http://www.day.com/jcr/a/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0";
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
>
>
>
> {code}
> Installing another package(second) with the same cnd file but with different
> child node's(default node) content.xml:
> {code:xml}
>
> http://www.day.com/jcr/a/1.0";
> xmlns:jcr="http://www.jcp.org/jcr/1.0";
> a:trigger="rollout"
> jcr:description="abc"
> jcr:primaryType="a:RolloutConfig"
> jcr:title="Standard rollout config">
>
>
>
> {code}
> marks the below node for Deletion but doesn't delete them because it's a
> mandatory node
> {code:xml}
> D /x/y/z/rolloutconfigs/default/contentDelete
> D /x/y/z/rolloutconfigs/default/contentUpdate
> D /x/y/z/rolloutconfigs/default/orderChildren
> D /x/y/z/rolloutconfigs/default/personalizationContentRollout
> D /x/y/z/rolloutconfigs/default/referencesUpdate
> {code}
> The issue lies at
> https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L1190
> . Here, check for the child node is mandatory or not is done after marking
> it for delete importInfo.onDeleted(path) which gives wrong information that
> the child node is deleted but in the repository, it still exists.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [jackrabbit-oak] mreutegg opened a new pull request #354: OAK-9535: Support recovery of large branch merge
mreutegg opened a new pull request #354: URL: https://github.com/apache/jackrabbit-oak/pull/354 Builds on top of #346. Adds test and minor code change. -- 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] (JCR-4725) Using jcr-server-2.14.X issue with PDF indexing
[ https://issues.apache.org/jira/browse/JCR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406692#comment-17406692 ] Roberto Santin commented on JCR-4725: - Yes, I use my pdf and indexing correctly. That's why I think about using log artifacts to check what's happening with my project in production > Using jcr-server-2.14.X issue with PDF indexing > --- > > Key: JCR-4725 > URL: https://issues.apache.org/jira/browse/JCR-4725 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server >Affects Versions: 2.14.8 >Reporter: Roberto Santin >Priority: Major > > Hi, > I using jcr-server-2.14.8 and pdfbox 1.8.X. Correctly index the pdf file. > I try upgrade to pdfbox 2.0.6 (version fix other problem with pdfs files), > but now, is not indexing files when I upload the file. > > My question is jcr-server-2.14.8, have a dependences with pdfbox (if true, > what version jcr-server I use with pdfbox 2.0.X?) > Can anyone help me? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [jackrabbit-oak] mreutegg commented on a change in pull request #346: OAK-9535 : support/fix recovery of large branch merge that could breach the 16MB document size restriction on MongoDB
mreutegg commented on a change in pull request #346:
URL: https://github.com/apache/jackrabbit-oak/pull/346#discussion_r698350304
##
File path:
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/LastRevRecoveryAgent.java
##
@@ -309,6 +317,8 @@ public void sweepUpdate(Map updates)
long startOfScan = clock.getTime();
long lastLog = startOfScan;
+final List pseudoBcRevs = new ArrayList();
Review comment:
Can use diamond operator.
```suggestion
final List pseudoBcRevs = new ArrayList<>();
```
##
File path:
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/LastRevRecoveryAgent.java
##
@@ -364,7 +374,41 @@ public void sweepUpdate(Map updates)
unsavedParents.put(path, lastRevForParents);
}
}
+// avoid recalculating the size of the updateOp upon every single
path
+// but also avoid doing it only after we hit the 16MB limit
+if (changes.getNumChangedNodes() >= nextFlushCheckCount) {
+final Revision pseudoBcRev =
Revision.newRevision(clusterId).asBranchRevision();
+final UpdateOp pseudoBcUpdateOp =
changes.asUpdateOp(pseudoBcRev);
+final int approxPseudoBcUpdateOpSize =
pseudoBcUpdateOp.toString().length();
+if (approxPseudoBcUpdateOpSize >=
PSEUDO_BRANCH_COMMIT_UPDATE_OP_THRESHOLD_BYTES) {
+// flush the (pseudo) journal entry
+// regarding 'pseudo' : this journal entry, while being a
branch commit,
+// does not correspond to an actual branch commit that
happened before the crash.
+// we might be able to in theory reconstruct the very
original branch commits,
+// but that's a tedious job, and we were not doing that
prior to OAK-9535 neither.
+// hence the optimization built-in here is that we create
a journal entry
+// of type 'branch commit', but with a revision that is
different from
+// what originally happened. Thx to the fact that the
JournalEntry just
+// contains a list of branch commit journal ids, that
should work fine.
+if (store.create(JOURNAL,
singletonList(pseudoBcUpdateOp))) {
+log.info("recover : created intermediate pseudo-bc
journal entry with rev {} and approx size {} bytes.",
+pseudoBcRev, approxPseudoBcUpdateOpSize);
+pseudoBcRevs.add(pseudoBcRev);
+changes = JOURNAL.newDocument(store);
+nextFlushCheckCount =
PSEUDO_BRANCH_COMMIT_FLUSH_CHECK_COUNT;
+} else {
+log.warn("recover : could not create intermediate
pseudo-bc journal entry with rev {}",
+pseudoBcRev);
+// retry a little later then, hence reduce the next
counter by half an interval
+nextFlushCheckCount += changes.getNumChangedNodes() +
(PSEUDO_BRANCH_COMMIT_FLUSH_CHECK_COUNT / 2);
Review comment:
I would rather fail recovery in this 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
[jira] [Comment Edited] (JCR-4725) Using jcr-server-2.14.X issue with PDF indexing
[ https://issues.apache.org/jira/browse/JCR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406118#comment-17406118 ] Julian Reschke edited comment on JCR-4725 at 8/30/21, 11:27 AM: Maybe you can modify the test to use the PDF you're trying? was (Author: reschke): Maybe you can mosify the test to use the PDF you're trying? > Using jcr-server-2.14.X issue with PDF indexing > --- > > Key: JCR-4725 > URL: https://issues.apache.org/jira/browse/JCR-4725 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-jcr-server >Affects Versions: 2.14.8 >Reporter: Roberto Santin >Priority: Major > > Hi, > I using jcr-server-2.14.8 and pdfbox 1.8.X. Correctly index the pdf file. > I try upgrade to pdfbox 2.0.6 (version fix other problem with pdfs files), > but now, is not indexing files when I upload the file. > > My question is jcr-server-2.14.8, have a dependences with pdfbox (if true, > what version jcr-server I use with pdfbox 2.0.X?) > Can anyone help me? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [jackrabbit-filevault] sonarcloud[bot] commented on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
sonarcloud[bot] commented on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908251516 Kudos, SonarCloud Quality Gate passed!  [](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_jackrabbit-filevault&pullRequest=162&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_jackrabbit-filevault&pullRequest=162&metric=coverage&view=list) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_jackrabbit-filevault&pullRequest=162&metric=new_duplicated_lines_density&view=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_jackrabbit-filevault&pullRequest=162&metric=new_duplicated_lines_density&view=list) -- 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] (JCR-4725) Using jcr-server-2.14.X issue with PDF indexing
[
https://issues.apache.org/jira/browse/JCR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406668#comment-17406668
]
Roberto Santin commented on JCR-4725:
-
OK,
in production there are no errors/alerts in the log. Can I use some feature to
identify if there are any configuration issues or exceptions for other
libraries?
I use:
{code:java}
// espaço reservado de código
{code}
Have another config for log?
> Using jcr-server-2.14.X issue with PDF indexing
> ---
>
> Key: JCR-4725
> URL: https://issues.apache.org/jira/browse/JCR-4725
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
>Affects Versions: 2.14.8
>Reporter: Roberto Santin
>Priority: Major
>
> Hi,
> I using jcr-server-2.14.8 and pdfbox 1.8.X. Correctly index the pdf file.
> I try upgrade to pdfbox 2.0.6 (version fix other problem with pdfs files),
> but now, is not indexing files when I upload the file.
>
> My question is jcr-server-2.14.8, have a dependences with pdfbox (if true,
> what version jcr-server I use with pdfbox 2.0.X?)
> Can anyone help me?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [jackrabbit-filevault] kwin commented on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
kwin commented on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908214373 @tripodsan In general filter rules seem to be observed except for one edge case. What is the idea of `Importer.postFilter` (https://github.com/apache/jackrabbit-filevault/blob/61e920f55e487aa5dc045c66ce5b7b5e444784ca/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Importer.java#L518)? Is that supposed to filter out everything on an artifact level not contained in a filter and the DocViewSAXImporter only does the filtering on sub artifact level? If so do you consider Importer.postFilter errorneous as it does not correctly filter out artifacts which are below a contained node (but excluded)? -- 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
[GitHub] [jackrabbit-oak] mreutegg merged pull request #353: OAK-9560 - Javadoc build fails if using Java11
mreutegg merged pull request #353: URL: https://github.com/apache/jackrabbit-oak/pull/353 -- 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
[GitHub] [jackrabbit-oak] mreutegg commented on pull request #353: OAK-9560 - Javadoc build fails if using Java11
mreutegg commented on pull request #353: URL: https://github.com/apache/jackrabbit-oak/pull/353#issuecomment-908192684 Looks good 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
[GitHub] [jackrabbit-oak] thomasmueller commented on a change in pull request #351: OAK-9552: Don't index except if it's oak:QueryIndexDefinition
thomasmueller commented on a change in pull request #351:
URL: https://github.com/apache/jackrabbit-oak/pull/351#discussion_r698269599
##
File path:
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/IndexUpdate.java
##
@@ -280,10 +296,19 @@ private void collectIndexEditors(NodeBuilder definitions,
NodeBuilder definition = definitions.getChildNode(name);
if (isIncluded(rootState.async, definition)) {
String type = definition.getString(TYPE_PROPERTY_NAME);
+String primaryType =
definition.getName(JcrConstants.JCR_PRIMARYTYPE);
if (type == null) {
// probably not an index def
continue;
}
+/*
+ Log a warning after every indexJcrTypeInvalidLogLimiter
cycles of indexer where nodeState changed.
+ */
+if
(!IndexConstants.INDEX_DEFINITIONS_NODE_TYPE.equals(primaryType)
+&& totalExecutionCount % indexJcrTypeInvalidLogLimiter
== 0) {
Review comment:
This isn't relevant here, but just FYI:
"%" (modulo) is a relatively slow CPU instructions (same as division).
Multiplication is faster, and bitwise and is even faster.
Here, in theory, it would be possible to use bitwise and, but then
indexJcrTypeInvalidLogLimiter would need to be a power of 2.
To avoid modulo for e.g. a hash map, when calculating the bucket from the
hash code, if the number of buckets isn't a power of 2, one can use
multiplication & shift. See
https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/
--
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
[GitHub] [jackrabbit-oak] thomasmueller commented on a change in pull request #351: OAK-9552: Don't index except if it's oak:QueryIndexDefinition
thomasmueller commented on a change in pull request #351: URL: https://github.com/apache/jackrabbit-oak/pull/351#discussion_r698261868 ## File path: oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/IndexUpdate.java ## @@ -72,6 +73,9 @@ private static final Logger log = LoggerFactory.getLogger(IndexUpdate.class); private static final String TYPE_ELASTICSEARCH = "elasticsearch"; +//This is used so that wrong index definitions are sparsely logged. After every 1000 indexing cycles with diff, wrong index definitions Review comment: By default the indexing cycle is once every 5 seconds. That mean 5000 seconds, or 83 minutes. I think that's a good value. ## File path: oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/IndexUpdate.java ## @@ -72,6 +73,9 @@ private static final Logger log = LoggerFactory.getLogger(IndexUpdate.class); private static final String TYPE_ELASTICSEARCH = "elasticsearch"; +//This is used so that wrong index definitions are sparsely logged. After every 1000 indexing cycles with diff, wrong index definitions Review comment: And for sync indexes, once in 1000 updates is fine as well I think. -- 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
[GitHub] [jackrabbit-filevault] kwin commented on pull request #162: JCRVLT-522 check effect of filter rules on ACLs
kwin commented on pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162#issuecomment-908102392 I fail to reproduce installation of ACLs not contained in the filter. @anchela Can you come up with a 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
[GitHub] [jackrabbit-filevault] kwin opened a new pull request #162: JCRVLT-522 check effect of filter rules on ACLs
kwin opened a new pull request #162: URL: https://github.com/apache/jackrabbit-filevault/pull/162 WIP -- 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-372) Clarify import and export behaviour for rep:policy nodes not contained in filter rules
[
https://issues.apache.org/jira/browse/JCRVLT-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-372:
---
Description:
It seems that {{rep:policy}} nodes do not necessarily have to be mentioned in
the {{filter.xml}} for being considered during package import and export. That
should be clarified in https://jackrabbit.apache.org/filevault/filter.html.
This was triggered by
https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/2045.
was:It seems that {{rep:policy}} nodes do not necessarily have to be
mentioned in the {{filter.xml}} for being considered during package import and
export. That should be clarified in
https://jackrabbit.apache.org/filevault/filter.html.
> Clarify import and export behaviour for rep:policy nodes not contained in
> filter rules
> --
>
> Key: JCRVLT-372
> URL: https://issues.apache.org/jira/browse/JCRVLT-372
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Konrad Windszus
>Priority: Major
>
> It seems that {{rep:policy}} nodes do not necessarily have to be mentioned in
> the {{filter.xml}} for being considered during package import and export.
> That should be clarified in
> https://jackrabbit.apache.org/filevault/filter.html.
> This was triggered by
> https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/2045.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
