[jira] [Comment Edited] (OAK-10038) CompositeStoreIT: add workaround for potential NPE in test
[ https://issues.apache.org/jira/browse/OAK-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649050#comment-17649050 ] Julian Reschke edited comment on OAK-10038 at 1/18/23 2:04 PM: --- trunk: [b07057dd0b|https://github.com/apache/jackrabbit-oak/commit/b07057dd0b00372be48a5a8d96b347bd6ecb1cf8] 1.22: (1.22.14) [3c58b41919|https://github.com/apache/jackrabbit-oak/commit/3c58b41919921d2b8a992e5b968c5970ed6d9903] was (Author: reschke): trunk: [b07057dd0b|https://github.com/apache/jackrabbit-oak/commit/b07057dd0b00372be48a5a8d96b347bd6ecb1cf8] 1.22: [3c58b41919|https://github.com/apache/jackrabbit-oak/commit/3c58b41919921d2b8a992e5b968c5970ed6d9903] > CompositeStoreIT: add workaround for potential NPE in test > -- > > Key: OAK-10038 > URL: https://issues.apache.org/jira/browse/OAK-10038 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: composite >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.22.14, 1.48.0 > > > (discovered and patch provided by [~kwin] in > https://github.com/apache/jackrabbit-oak/commit/fcf75771d16f1c89e7c62441ef67f0ad3f37006c#diff-8d5c4d63487006489ece4fe452589dab3886dd79c54ce82b90cae742e0e91279) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10031) Remove unmerged branches and collisions in batches
[ https://issues.apache.org/jira/browse/OAK-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678244#comment-17678244 ] Julian Reschke commented on OAK-10031: -- trunk: [e84a0b14a3|https://github.com/apache/jackrabbit-oak/commit/e84a0b14a3c2660825bbf7d91c92d62fec0b2a92] [f1faa48844|https://github.com/apache/jackrabbit-oak/commit/f1faa48844d6c847d0e03788db093b7f92e27e8f] > Remove unmerged branches and collisions in batches > -- > > Key: OAK-10031 > URL: https://issues.apache.org/jira/browse/OAK-10031 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Affects Versions: 1.44.0 >Reporter: Rishabh Kumar >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.48.0 > > > Cleaning of unmerged branches or collisions in one single update call to > MongoDB can block DocumentNodeStore initialization because the call on > MongoDB server can conflict repeatedly and is retried many times. > The cleanup should be broken into smaller batches that are easier to digest > for MongoDB. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10033) Conditions on dates use the wrong range
[
https://issues.apache.org/jira/browse/OAK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678245#comment-17678245
]
Julian Reschke commented on OAK-10033:
--
[~mkataria] - should this be set to resolved???
> Conditions on dates use the wrong range
> ---
>
> Key: OAK-10033
> URL: https://issues.apache.org/jira/browse/OAK-10033
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
>
> For queries like:
> SELECT * FROM [nt:base] AS main WHERE (main.[startTime] <>
> cast('1971-01-01T13:00:00.000Z' AS date))
> The condition uses the wrong range, as negative values are possible. The
> range should be -9223372036854775808 TO 9223372036854775807 and not 0 TO
> 9223372036854775807.
> {code:java}
> [calendar@startTime] <> cast('1971-01-01T13:00:00.000Z' AS date)
> +calendar@startTime:[0 TO 9223372036854775807]
> -calendar@startTime:[3158280 TO 3158280]{code}
> Source code:
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/PropertyValueImpl.java]
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1227]
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, 0L, Long.MAX_VALUE, true,
> true);{code}
> This isn't correct, as 0 means 1970-01-01T00:00:00.000Z
> It should probably be :
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, Long.MIN_VALUE,
> Long.MAX_VALUE, true, true);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10033) Conditions on dates use the wrong range
[
https://issues.apache.org/jira/browse/OAK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-10033:
-
Fix Version/s: 1.48.0
> Conditions on dates use the wrong range
> ---
>
> Key: OAK-10033
> URL: https://issues.apache.org/jira/browse/OAK-10033
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
> Fix For: 1.48.0
>
>
> For queries like:
> SELECT * FROM [nt:base] AS main WHERE (main.[startTime] <>
> cast('1971-01-01T13:00:00.000Z' AS date))
> The condition uses the wrong range, as negative values are possible. The
> range should be -9223372036854775808 TO 9223372036854775807 and not 0 TO
> 9223372036854775807.
> {code:java}
> [calendar@startTime] <> cast('1971-01-01T13:00:00.000Z' AS date)
> +calendar@startTime:[0 TO 9223372036854775807]
> -calendar@startTime:[3158280 TO 3158280]{code}
> Source code:
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/PropertyValueImpl.java]
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1227]
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, 0L, Long.MAX_VALUE, true,
> true);{code}
> This isn't correct, as 0 means 1970-01-01T00:00:00.000Z
> It should probably be :
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, Long.MIN_VALUE,
> Long.MAX_VALUE, true, true);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10051) oak-run and oak-upgrade JARs incomplete (META-INF/MANIFEST.MF is missing the Main-Class entry)
[
https://issues.apache.org/jira/browse/OAK-10051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678247#comment-17678247
]
Julian Reschke commented on OAK-10051:
--
trunk:
[af958d39ce|https://github.com/apache/jackrabbit-oak/commit/af958d39ce6ce3e03434276a917de4ad94f6b5ca]
> oak-run and oak-upgrade JARs incomplete (META-INF/MANIFEST.MF is missing the
> Main-Class entry)
> --
>
> Key: OAK-10051
> URL: https://issues.apache.org/jira/browse/OAK-10051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run, upgrade
>Affects Versions: 1.46.0
>Reporter: Torsten Stolpmann
>Assignee: Konrad Windszus
>Priority: Major
> Labels: candidate_oak_1_22
> Fix For: 1.48.0
>
>
> This is a regression from 1.44.0 and previous versions, where the entry was
> still present.
>
> Without this entry it is no longer possible to use
> {{java - jar oak-run.jar}}
> and
> {{java - jar oak-upgrade.jar}}
> CLI invocations directly.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10054) Improved trace level logging of JCR method calls
[ https://issues.apache.org/jira/browse/OAK-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678250#comment-17678250 ] Julian Reschke commented on OAK-10054: -- trunk: [2634e8f53e|https://github.com/apache/jackrabbit-oak/commit/2634e8f53e652c5fe69b87453f96312b05895da3] [9f2f57d2ec|https://github.com/apache/jackrabbit-oak/commit/9f2f57d2ec53d82a4505e82513402e4943130fe8] [40a666805c|https://github.com/apache/jackrabbit-oak/commit/40a666805c75a60a14624f621fad7dedd937d4ca] [cdc854cb9e|https://github.com/apache/jackrabbit-oak/commit/cdc854cb9e409a88df49ce9ff76635b71f103351] > Improved trace level logging of JCR method calls > > > Key: OAK-10054 > URL: https://issues.apache.org/jira/browse/OAK-10054 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.48.0 > > Attachments: OAK-10054.patch > > > To analyze calls to the JCR API we can enable trace level logging. However, > currently only the operation is logged (e.g. getNode), but not the path. > Also, applications that have thousands of JCR method calls will write too > many log messages. > That means we currently have both too much logging (too many lines), and not > enough logging (not logging useful info). > It would be good if with trace level setting enabled, JCR method calls are > logged in more detail (e.g. path), and optionally with sampling. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10055) Auto refreshing IndexTracker every hour causes online reindexing to fail
[
https://issues.apache.org/jira/browse/OAK-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678252#comment-17678252
]
Julian Reschke commented on OAK-10055:
--
trunk:
[bf2832e7c4|https://github.com/apache/jackrabbit-oak/commit/bf2832e7c496526c9abcf8dd208b2445a6371aad]
1.22: (1.22.14)
[16886413d6|https://github.com/apache/jackrabbit-oak/commit/16886413d6457fd4bd75f0bedc563376b8a7e4cb]
> Auto refreshing IndexTracker every hour causes online reindexing to fail
>
>
> Key: OAK-10055
> URL: https://issues.apache.org/jira/browse/OAK-10055
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Affects Versions: 1.22.9
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Labels: lucene
> Fix For: 1.22.14, 1.48.0
>
>
> Auto refreshing the index tracker every one hour
> https://github.com/apache/jackrabbit-oak/commit/37a6d47b27cd7393812fa34c23b5dc68170daef3
> , which was done to fix potential SNFE issue seems to be causing online
> reindexing for those indexes that take more than an hour to reindex to fail.
> In addition to reindexing, it looks like there is another scenario whenever a
> default 1h auto-refreshing IndexTracker results in an error, even thought it
> doesn't seem to be as severe:
> {noformat}
> Caused by: java.io.FileNotFoundException: _b.dvd
> at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:261)
> at
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:178)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.DirectoryUtils.dirSize(DirectoryUtils.java:61)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex$NRTReader.getIndexSize(NRTIndex.java:382)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexMBeanImpl.getIndexSize(LuceneIndexMBeanImpl.java:840)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexMBeanImpl.access$400(LuceneIndexMBeanImpl.java:98)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexMBeanImpl$IndexStats.(LuceneIndexMBeanImpl.java:746)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexMBeanImpl.getIndexStats(LuceneIndexMBeanImpl.java:131)
> at sun.reflect.GeneratedMethodAccessor522.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> ... 13 common frames omitted
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10034) Periodically clean up unmerged branch commits and collision markers
[ https://issues.apache.org/jira/browse/OAK-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-10034: - Component/s: documentmk > Periodically clean up unmerged branch commits and collision markers > --- > > Key: OAK-10034 > URL: https://issues.apache.org/jira/browse/OAK-10034 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Rishabh Kumar >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.48.0 > > > Unmerged branch commits and collision markers are currently cleaned up only > on initialization of a DocumentNodeStore. > Consider a periodic task scheduled by active DocumentNodeStore instances that > check for unmerged branch commits and collision markers on the root document > from inactive clusterIds. These can be removed because those commits can > never be merged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10034) Periodically clean up unmerged branch commits and collision markers
[ https://issues.apache.org/jira/browse/OAK-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678256#comment-17678256 ] Julian Reschke commented on OAK-10034: -- trunk: [df53ab2ae7|https://github.com/apache/jackrabbit-oak/commit/df53ab2ae7e42cafb2676be1b006054c373399f8] [00ac096cbb|https://github.com/apache/jackrabbit-oak/commit/00ac096cbb2ba2afb29a3499b62463b197b583b1] [ed19990895|https://github.com/apache/jackrabbit-oak/commit/ed19990895edeaa9337c1ab84f2ac722f53af908] > Periodically clean up unmerged branch commits and collision markers > --- > > Key: OAK-10034 > URL: https://issues.apache.org/jira/browse/OAK-10034 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Rishabh Kumar >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.48.0 > > > Unmerged branch commits and collision markers are currently cleaned up only > on initialization of a DocumentNodeStore. > Consider a periodic task scheduled by active DocumentNodeStore instances that > check for unmerged branch commits and collision markers on the root document > from inactive clusterIds. These can be removed because those commits can > never be merged. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10059) webapp: avoid use of Jackrabbit's transitive commons-collections dependency
[ https://issues.apache.org/jira/browse/OAK-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656499#comment-17656499 ] Julian Reschke edited comment on OAK-10059 at 1/18/23 2:24 PM: --- trunk: [cd074bbb84|https://github.com/apache/jackrabbit-oak/commit/cd074bbb8489070b52af3d8f7ceb42ee9eb09c30] 1.22: (1.22.14) [dcf7e2d0a1|https://github.com/apache/jackrabbit-oak/commit/dcf7e2d0a1fd3716178962e175b5ba6830d26bea] was (Author: reschke): trunk: [cd074bbb84|https://github.com/apache/jackrabbit-oak/commit/cd074bbb8489070b52af3d8f7ceb42ee9eb09c30] 1.22: [dcf7e2d0a1|https://github.com/apache/jackrabbit-oak/commit/dcf7e2d0a1fd3716178962e175b5ba6830d26bea] > webapp: avoid use of Jackrabbit's transitive commons-collections dependency > --- > > Key: OAK-10059 > URL: https://issues.apache.org/jira/browse/OAK-10059 > Project: Jackrabbit Oak > Issue Type: Task > Components: examples >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.22.14, 1.48.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10057) Update Oak trunk and Oak 1.22 to Jackrabbit 2.20.8
[ https://issues.apache.org/jira/browse/OAK-10057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656549#comment-17656549 ] Julian Reschke edited comment on OAK-10057 at 1/18/23 2:26 PM: --- trunk: [13277a74f1|https://github.com/apache/jackrabbit-oak/commit/13277a74f1fe0ee5532d6ebc21e22365b502ddd6] 1.22: (1.22.14) [800718600f|https://github.com/apache/jackrabbit-oak/commit/800718600f7bf9fa50042933c5ff137e4155537b] was (Author: reschke): trunk: [13277a74f1|https://github.com/apache/jackrabbit-oak/commit/13277a74f1fe0ee5532d6ebc21e22365b502ddd6] 1.22: [800718600f|https://github.com/apache/jackrabbit-oak/commit/800718600f7bf9fa50042933c5ff137e4155537b] > Update Oak trunk and Oak 1.22 to Jackrabbit 2.20.8 > -- > > Key: OAK-10057 > URL: https://issues.apache.org/jira/browse/OAK-10057 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.22.14, 1.48.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10056) Provide support for Jakarta Region for AWS S3
[ https://issues.apache.org/jira/browse/OAK-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678260#comment-17678260 ] Julian Reschke commented on OAK-10056: -- trunk: [dee89565e4|https://github.com/apache/jackrabbit-oak/commit/dee89565e4bbfa1e596d2c3d490b39366f734a18] > Provide support for Jakarta Region for AWS S3 > - > > Key: OAK-10056 > URL: https://issues.apache.org/jira/browse/OAK-10056 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob-cloud, segment-aws >Reporter: Rishabh Kumar >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.48.0 > > > We need to provide support for Jakarta Region for S3 buckets. This would > require us to update the aws java sdk version from 1.11.700 to 1.12.133+. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10056) Provide support for Jakarta Region for AWS S3
[ https://issues.apache.org/jira/browse/OAK-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-10056: - Component/s: blob-cloud segment-aws > Provide support for Jakarta Region for AWS S3 > - > > Key: OAK-10056 > URL: https://issues.apache.org/jira/browse/OAK-10056 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob-cloud, segment-aws >Reporter: Rishabh Kumar >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.48.0 > > > We need to provide support for Jakarta Region for S3 buckets. This would > require us to update the aws java sdk version from 1.11.700 to 1.12.133+. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10061) WARN when for an external group a local group with the same name is already present
[ https://issues.apache.org/jira/browse/OAK-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678263#comment-17678263 ] Julian Reschke commented on OAK-10061: -- trunk: [109a22af7b|https://github.com/apache/jackrabbit-oak/commit/109a22af7b17256916d0a0023662c194d31fe08e] > WARN when for an external group a local group with the same name is already > present > --- > > Key: OAK-10061 > URL: https://issues.apache.org/jira/browse/OAK-10061 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: auth-external >Affects Versions: 1.46.0, 1.22.13 >Reporter: Joerg Hoh >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > > When a local group named "group" is present, any sync of an external group > (from an IDP) with the same name fails silently. > There should be a WARN like this: "Cannot create externally managed group > named XX because a local group with the same name already exists; principal Y > will miss group memberships" in the logs to make this problem obvious and to > ease the debugging of this situation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10063) AsyncIndexUpdate - Logger not printing complete message
[ https://issues.apache.org/jira/browse/OAK-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17675864#comment-17675864 ] Julian Reschke edited comment on OAK-10063 at 1/18/23 2:32 PM: --- trunk: [bebc0d401a|https://github.com/apache/jackrabbit-oak/commit/bebc0d401aae02b113eb9cf8116c7c9aae2a2c12] was (Author: nitigup): trunk : [https://github.com/apache/jackrabbit-oak/commit/bebc0d401aae02b113eb9cf8116c7c9aae2a2c12] > AsyncIndexUpdate - Logger not printing complete message > --- > > Key: OAK-10063 > URL: https://issues.apache.org/jira/browse/OAK-10063 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.48.0 > > > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/AsyncIndexUpdate.java#L1099] > > > This here doesn't print the e.getMessage() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10067) ExternalGroupPrincipalProvider does not resolve inherited groups that cross IDP boundaries
[ https://issues.apache.org/jira/browse/OAK-10067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678265#comment-17678265 ] Julian Reschke commented on OAK-10067: -- trunk: [edf4a4493c|https://github.com/apache/jackrabbit-oak/commit/edf4a4493c18784c83d3e50d26739b458c374a11] > ExternalGroupPrincipalProvider does not resolve inherited groups that cross > IDP boundaries > -- > > Key: OAK-10067 > URL: https://issues.apache.org/jira/browse/OAK-10067 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Reporter: Angela Schreiber >Assignee: Angela Schreiber >Priority: Major > Fix For: 1.48.0 > > > if a dynamic group is member of group that does not belong to the same IDP > (such as e.g. a local group that is not listed in automembership), the > ExternalGroupPrincipalProvider will fail to resolve the inherited membership > for external users. > Note that resolving the membership of the dynamic group itself works, but for > external members of that dynamic group (i.e. external users) the IDP-boundary > crossing membership will not be resolved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10033) Conditions on dates use the wrong range
[
https://issues.apache.org/jira/browse/OAK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta resolved OAK-10033.
---
Resolution: Fixed
> Conditions on dates use the wrong range
> ---
>
> Key: OAK-10033
> URL: https://issues.apache.org/jira/browse/OAK-10033
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
> Fix For: 1.48.0
>
>
> For queries like:
> SELECT * FROM [nt:base] AS main WHERE (main.[startTime] <>
> cast('1971-01-01T13:00:00.000Z' AS date))
> The condition uses the wrong range, as negative values are possible. The
> range should be -9223372036854775808 TO 9223372036854775807 and not 0 TO
> 9223372036854775807.
> {code:java}
> [calendar@startTime] <> cast('1971-01-01T13:00:00.000Z' AS date)
> +calendar@startTime:[0 TO 9223372036854775807]
> -calendar@startTime:[3158280 TO 3158280]{code}
> Source code:
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/PropertyValueImpl.java]
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1227]
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, 0L, Long.MAX_VALUE, true,
> true);{code}
> This isn't correct, as 0 means 1970-01-01T00:00:00.000Z
> It should probably be :
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, Long.MIN_VALUE,
> Long.MAX_VALUE, true, true);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10033) Conditions on dates use the wrong range
[
https://issues.apache.org/jira/browse/OAK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678289#comment-17678289
]
Nitin Gupta commented on OAK-10033:
---
trunk :
[https://github.com/apache/jackrabbit-oak/commit/9d91389b6eaf1a0bb790204643b2ce03531fe624]
> Conditions on dates use the wrong range
> ---
>
> Key: OAK-10033
> URL: https://issues.apache.org/jira/browse/OAK-10033
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
> Fix For: 1.48.0
>
>
> For queries like:
> SELECT * FROM [nt:base] AS main WHERE (main.[startTime] <>
> cast('1971-01-01T13:00:00.000Z' AS date))
> The condition uses the wrong range, as negative values are possible. The
> range should be -9223372036854775808 TO 9223372036854775807 and not 0 TO
> 9223372036854775807.
> {code:java}
> [calendar@startTime] <> cast('1971-01-01T13:00:00.000Z' AS date)
> +calendar@startTime:[0 TO 9223372036854775807]
> -calendar@startTime:[3158280 TO 3158280]{code}
> Source code:
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/PropertyValueImpl.java]
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1227]
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, 0L, Long.MAX_VALUE, true,
> true);{code}
> This isn't correct, as 0 means 1970-01-01T00:00:00.000Z
> It should probably be :
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, Long.MIN_VALUE,
> Long.MAX_VALUE, true, true);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
