[jira] [Commented] (OAK-7182) Make it possible to update Guava
[
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557617#comment-17557617
]
Dawid Iwo Cokan commented on OAK-7182:
--
Hi [~reschke]
We use Guava 15 as mentioned but problem with using different version by
clients is not because of used version (nor the fact of exposed Guava code in
OAK APIs) but because Guava makes incompatible changes, right?
Based on Guava [statement|https://github.com/google/guava] starting from 22.0
all their APIs will remain compatible unless they are _@Beta:_
{quote}APIs without {{@Beta}} will remain binary-compatible for the indefinite
future. (Previously, we sometimes removed such APIs after a deprecation period.
The last release to remove non-{{{}@Beta{}}} APIs was Guava 21.0.) Even
{{@Deprecated}} APIs will remain (again, unless they are {{{}@Beta{}}}). We
have no plans to start removing things again, but officially, we're leaving our
options open in case of surprises (like, say, a serious security problem).
{quote}
So correct me if I am wrong but clients would be free to chose the Guava
version (whichever higher than 22.0) if we:
* Depend on 22.0 Guava
* Declare Import-Package as [22.0,)
* Include [Guava Beta Checker|https://github.com/google/guava-beta-checker] in
build chain to ensure no code depends on code that potentially does not exist
in future releases
> Make it possible to update Guava
>
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
> Issue Type: Wish
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff,
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff,
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in
> order to make updates possible.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (OAK-9773) DefaultSyncContext#syncMembership() compares external ids case-sensitively
[ https://issues.apache.org/jira/browse/OAK-9773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved OAK-9773. - Resolution: Fixed > DefaultSyncContext#syncMembership() compares external ids case-sensitively > --- > > Key: OAK-9773 > URL: https://issues.apache.org/jira/browse/OAK-9773 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Affects Versions: 1.42.0 >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Labels: candidate_oak_1_22 > Fix For: 1.44.0 > > Attachments: OAK-9773.patch > > > DefaultSyncContext#syncMembership() uses ids of Authorizables as keys in > HashMaps. Since UserManagerImpl#getAuthorizable(String) works > case-insensitively, this leads to misbehavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (OAK-9773) DefaultSyncContext#syncMembership() compares external ids case-sensitively
[ https://issues.apache.org/jira/browse/OAK-9773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557542#comment-17557542 ] Manfred Baedke commented on OAK-9773: - PR merged. > DefaultSyncContext#syncMembership() compares external ids case-sensitively > --- > > Key: OAK-9773 > URL: https://issues.apache.org/jira/browse/OAK-9773 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Affects Versions: 1.42.0 >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Labels: candidate_oak_1_22 > Attachments: OAK-9773.patch > > > DefaultSyncContext#syncMembership() uses ids of Authorizables as keys in > HashMaps. Since UserManagerImpl#getAuthorizable(String) works > case-insensitively, this leads to misbehavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (OAK-9773) DefaultSyncContext#syncMembership() compares external ids case-sensitively
[ https://issues.apache.org/jira/browse/OAK-9773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-9773: Fix Version/s: 1.44.0 > DefaultSyncContext#syncMembership() compares external ids case-sensitively > --- > > Key: OAK-9773 > URL: https://issues.apache.org/jira/browse/OAK-9773 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-external >Affects Versions: 1.42.0 >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Labels: candidate_oak_1_22 > Fix For: 1.44.0 > > Attachments: OAK-9773.patch > > > DefaultSyncContext#syncMembership() uses ids of Authorizables as keys in > HashMaps. Since UserManagerImpl#getAuthorizable(String) works > case-insensitively, this leads to misbehavior. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (OAK-9767) Support Int / Long Terms in LuceneIndexMBean
[ https://issues.apache.org/jira/browse/OAK-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-9767. - Resolution: Fixed > Support Int / Long Terms in LuceneIndexMBean > > > Key: OAK-9767 > URL: https://issues.apache.org/jira/browse/OAK-9767 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Dan Klco >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.44.0 > > > Currently, the LuceneIndexMbean only supports retrieving terms of the type > String via the > [BytesRef.utf8ToString|https://lucene.apache.org/core/7_2_1/core/org/apache/lucene/util/BytesRef.html#utf8ToString--] > method. Terms of type Int and Long are corrupted and will not display > properly when retrieved with this method. > > To support retrieving Long / Int terms, a new method should be added to the > LuceneIndexMbean which takes a type string and based on that type string > determines how to retrieve the term. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (OAK-9767) Support Int / Long Terms in LuceneIndexMBean
[ https://issues.apache.org/jira/browse/OAK-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557536#comment-17557536 ] Thomas Mueller commented on OAK-9767: - Merged on 2022-06-22 > Support Int / Long Terms in LuceneIndexMBean > > > Key: OAK-9767 > URL: https://issues.apache.org/jira/browse/OAK-9767 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Dan Klco >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.44.0 > > > Currently, the LuceneIndexMbean only supports retrieving terms of the type > String via the > [BytesRef.utf8ToString|https://lucene.apache.org/core/7_2_1/core/org/apache/lucene/util/BytesRef.html#utf8ToString--] > method. Terms of type Int and Long are corrupted and will not display > properly when retrieved with this method. > > To support retrieving Long / Int terms, a new method should be added to the > LuceneIndexMbean which takes a type string and based on that type string > determines how to retrieve the term. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (OAK-9767) Support Int / Long Terms in LuceneIndexMBean
[ https://issues.apache.org/jira/browse/OAK-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned OAK-9767: --- Assignee: Thomas Mueller > Support Int / Long Terms in LuceneIndexMBean > > > Key: OAK-9767 > URL: https://issues.apache.org/jira/browse/OAK-9767 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Dan Klco >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.44.0 > > > Currently, the LuceneIndexMbean only supports retrieving terms of the type > String via the > [BytesRef.utf8ToString|https://lucene.apache.org/core/7_2_1/core/org/apache/lucene/util/BytesRef.html#utf8ToString--] > method. Terms of type Int and Long are corrupted and will not display > properly when retrieved with this method. > > To support retrieving Long / Int terms, a new method should be added to the > LuceneIndexMbean which takes a type string and based on that type string > determines how to retrieve the term. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (OAK-9442) LDAPIdentityProvider: avoid usage of weak SSL/TLS protocol
[
https://issues.apache.org/jira/browse/OAK-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-9442:
Summary: LDAPIdentityProvider: avoid usage of weak SSL/TLS protocol (was:
LDAPIdentityProvider: avoid usage of week SSL/TLS protocol)
> LDAPIdentityProvider: avoid usage of weak SSL/TLS protocol
> --
>
> Key: OAK-9442
> URL: https://issues.apache.org/jira/browse/OAK-9442
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Reporter: Angela Schreiber
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-9442.patch
>
>
> sonar issues a warning regarding usage of week SSL/TLS protocols the
> following code in {{LDAPIdentityProvider}}:
> {code}
> // make sure the JVM supports the TLSv1.1
> try {
> enabledSSLProtocols = null;
> SSLContext.getInstance("TLSv1.1");
> } catch (NoSuchAlgorithmException e) {
> log.warn("JDK does not support TLSv1.1. Disabling it.");
> enabledSSLProtocols = new String[]{"TLSv1"};
> }
> {code}
> This code has been introduced with OAK-2951 (Regression: SSL errors with
> latest ldap client). My preference for addressing this would be to drop the
> try/catch altogether and replace with an optional configuration option that
> allows to explicitly defined protocols to be enabled on the
> {{LDAPConnectionConfiguration}}.
> The downside of this approach: current usage of the oak-auth-ldap that relied
> on having an automatic fallback to TLSv1 installed would no longer work.
> However, I am not sure how big that risk is, given that TLSv1.2 is required
> to be supported since java 9
> (https://docs.oracle.com/javase/9/docs/api/javax/net/ssl/SSLContext.html)
> [~chaotic], [~insuafer], what do you think?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (OAK-9812) TokenConfigurationImpl does not define Context
[
https://issues.apache.org/jira/browse/OAK-9812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-9812.
---
Fix Version/s: 1.44.0
Resolution: Fixed
> TokenConfigurationImpl does not define Context
> --
>
> Key: OAK-9812
> URL: https://issues.apache.org/jira/browse/OAK-9812
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.44.0
>
>
> while testing some initial draft for OAK-9799, i noticed that the
> {{TokenConfigurationImpl}} does not define a dedicated {{Context}}
> implementation.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (OAK-9814) Improvements in NodeState/VersionCopier for visibility of paths added and preserve sub-paths
Amit Jain created OAK-9814: -- Summary: Improvements in NodeState/VersionCopier for visibility of paths added and preserve sub-paths Key: OAK-9814 URL: https://issues.apache.org/jira/browse/OAK-9814 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Amit Jain Assignee: Amit Jain Fix For: 1.44.0 Add an optional consumer to enable caller to have visibility on the paths added. This could be used by consumers to log, update metrics and if need be commit the transaction. Also, add an option to preserve sub paths on target in case it cannot be controlled by the current merge paths property. This is particularly the case when VersionCopier is used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
