[jira] [Updated] (OAK-4672) Allow disabling of auto-reindex mode
[ https://issues.apache.org/jira/browse/OAK-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-4672: -- Labels: (was: candidate_oak_1_2 candidate_oak_1_4) > Allow disabling of auto-reindex mode > > > Key: OAK-4672 > URL: https://issues.apache.org/jira/browse/OAK-4672 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > > In the case of a missing checkpoint, the indexer will trigger a full-reindex > in an attempt to self-heal. This is a very resource intensive operation, and > from an operations pov it makes sense to have it behind a flag, so it can be > triggered in a controlled manner. > Not having the auto-reindex mechanism enabled would mean that the index would > serve stale data for a longer period of time (basically until the reindex > finishes, whenever that may be in the future). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-4672) Allow disabling of auto-reindex mode
[ https://issues.apache.org/jira/browse/OAK-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882026#comment-16882026 ] Alex Deparvu commented on OAK-4672: --- not a problem, I closed and removed the labels. > Allow disabling of auto-reindex mode > > > Key: OAK-4672 > URL: https://issues.apache.org/jira/browse/OAK-4672 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > > In the case of a missing checkpoint, the indexer will trigger a full-reindex > in an attempt to self-heal. This is a very resource intensive operation, and > from an operations pov it makes sense to have it behind a flag, so it can be > triggered in a controlled manner. > Not having the auto-reindex mechanism enabled would mean that the index would > serve stale data for a longer period of time (basically until the reindex > finishes, whenever that may be in the future). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-4672) Allow disabling of auto-reindex mode
[ https://issues.apache.org/jira/browse/OAK-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-4672. --- Resolution: Won't Fix > Allow disabling of auto-reindex mode > > > Key: OAK-4672 > URL: https://issues.apache.org/jira/browse/OAK-4672 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Labels: candidate_oak_1_2, candidate_oak_1_4 > > In the case of a missing checkpoint, the indexer will trigger a full-reindex > in an attempt to self-heal. This is a very resource intensive operation, and > from an operations pov it makes sense to have it behind a flag, so it can be > triggered in a controlled manner. > Not having the auto-reindex mechanism enabled would mean that the index would > serve stale data for a longer period of time (basically until the reindex > finishes, whenever that may be in the future). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8442) AbstractCredentials.setAttributes sychronizes the wrong map
[
https://issues.apache.org/jira/browse/OAK-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16873249#comment-16873249
]
Alex Deparvu commented on OAK-8442:
---
very good find! +1
> AbstractCredentials.setAttributes sychronizes the wrong map
> ---
>
> Key: OAK-8442
> URL: https://issues.apache.org/jira/browse/OAK-8442
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.16.0
>
>
> [~stillalex], it seems to me that {{AbstractCredentials.setAttributes}}
> synchronizes the wrong attributes map:
> {code}
> public void setAttributes(@NotNull Map attributes) {
> synchronized (attributes) {
> this.attributes.putAll(attributes);
> }
> }
> {code}
> if you agree, i would change it to
> {code}
> public void setAttributes(@NotNull Map attributes) {
> synchronized (this.attributes) {
> this.attributes.putAll(attributes);
> }
> }
> {code}
> wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8408) UserImporter must not trigger creation of rep:pwd node unless included in xml (initial-pw-change)
[
https://issues.apache.org/jira/browse/OAK-8408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867705#comment-16867705
]
Alex Deparvu commented on OAK-8408:
---
[~angela] I have to admit as far as regression evaluation goes my understanding
of this code is limited so can't really comment. what about adding a flag that
reverts back to current behavior if really needed?
Otherwise changes look good to me.
> UserImporter must not trigger creation of rep:pwd node unless included in xml
> (initial-pw-change)
> -
>
> Key: OAK-8408
> URL: https://issues.apache.org/jira/browse/OAK-8408
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-8408-tests.patch, OAK-8408.patch
>
>
> when xml-importing an existing user (i.e. {{Tree}} doesn't have status NEW
> upon import) calling {{UserManagerImpl.setPassword}} will force the creation
> of the {{rep:pwd}} node and {{rep:passwordLastModified}} property contained
> therein _if_ theinitial-password-change feature is enabled.
> imo the {{rep:pwd}} (and any properties contained therein) must not be
> auto-created by should only be imported if contained in the XML.
> proposed fix: {{UserManagerImpl.setPassword}} already contains special
> treatment for the password hashing triggered upon xml import -> renaming that
> flag and respect it for the handling of the pw last modified.
> [~stillalex], wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842166#comment-16842166 ] Alex Deparvu commented on OAK-7217: --- the trouble is that all of these exported classes cannot be touched without breaking backwards compatibility (from OSGI's pov), independent of how easy it is to replace with jdk alternatives, unfortunately. > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, > fileutils-no-commons.diff, guava-global.log, guava-public-v2.log, > guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841259#comment-16841259
]
Alex Deparvu edited comment on OAK-7217 at 5/16/19 3:31 PM:
Hit a bottleneck with the bash approach, so I decided to build a proper
dependency analyzer: [wip
branch|https://github.com/stillalex/jackrabbit-oak/tree/foreing-apis].
The report can be generated under {{oak-run}}.
This is what I have so far. the output is a bit raw, but readable, it includes
and public method/variable from an exported package that receives/returns
objects that are not Oak or jdk.
* oak-run-commons
* oak-core
{code}
oajo.plugins.observation.filter.FilterBuilder#property,(Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Ljava/lang/String;Lcom/google/common/base/Predicate;)Lorg/apache/jackrabbit/oak/plugins/observation/filter/FilterBuilder$Condition;
oajo.plugins.observation.filter.FilterBuilder#universal,(Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Lcom/google/common/base/Predicate;)Lorg/apache/jackrabbit/oak/plugins/observation/filter/FilterBuilder$Condition;
oajo.plugins.observation.filter.UniversalFilter#,(Lorg/apache/jackrabbit/oak/spi/state/NodeState;Lorg/apache/jackrabbit/oak/spi/state/NodeState;Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Lcom/google/common/base/Predicate;)V
oajo.plugins.observation.filter.PropertyPredicate#,(Ljava/lang/String;Lcom/google/common/base/Predicate;)V
oajo.plugins.observation.filter.FilterBuilder$UniversalCondition#,(Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Lcom/google/common/base/Predicate;)V
oajo.plugins.migration.report.LoggingReporter#,(Lorg/slf4j/Logger;II)V
oajo.plugins.migration.report.LoggingReporter#,(Lorg/slf4j/Logger;Ljava/lang/String;II)V
oajo.plugins.index.property.strategy.IndexStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
oajo.plugins.index.property.strategy.IndexStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
oajo.plugins.index.property.strategy.UniqueEntryStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
oajo.plugins.index.property.strategy.UniqueEntryStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
oajo.plugins.index.property.strategy.ContentMirrorStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
oajo.plugins.index.property.strategy.ContentMirrorStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
oajo.plugins.index.property.strategy.FilteringIndexStoreStrategy#,(Lorg/apache/jackrabbit/oak/plugins/index/property/strategy/IndexStoreStrategy;Lcom/google/common/base/Predicate;)V
oajo.plugins.index.property.strategy.FilteringIndexStoreStrategy#,(Lorg/apache/jackrabbit/oak/plugins/index/property/strategy/IndexStoreStrategy;Lcom/google/common/base/Predicate;Z)V
oajo.plugins.index.property.strategy.FilteringIndexStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
oajo.plugins.index.property.strategy.FilteringIndexStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
{code}
* oak-store-composite
* oak-segment-azure
* oak-jcr
* oak-store-spi
{code}
oajo.spi.state.RevisionGC#,(Ljava/lang/Runnable;Ljava/lang/Runnable;Lcom/google/common/base/Supplier;Ljava/util/concurrent/Executor;)V
oajo.spi.state.NodeState#EXISTS,Lcom/google/common/base/Predicate;
oajo.spi.state.ChildNodeEntry#GET_NAME,Lcom/google/common/base/Function;
oajo.spi.commit.ProgressNotificationEditor#wrap,(Lorg/apache/jackrabbit/oak/spi/commit/Editor;Lorg/slf4j/Logger;Ljava/lang/String;)Lorg/apache/jackrabbit/oak/spi/commit/Editor;
oajo.plugins.memory.AbstractBlob#calculateSha256,(Lorg/apache/jackrabbit/oak/api/Blob;)Lcom/google/common/hash/HashCode;
oajo.plugins.memory.AbstractBlob#,(Lcom/google/common/hash/HashCode;)V
{code}
* oak-security-spi
{code}
oajo.spi.security.authentication.credentials.SimpleCredentialsSupport#getCredentialClasses,()Lcom/google/common/collect/ImmutableSet;
{code}
* oak-commons
{code}
oajo.commons.FileIOUtils$TransformingComparator#,(Ljava/util/Comparator;Lcom/google/common/base/Function;)V
oajo.commons.PerfLogger#,(Lorg/slf4j/Logger;)V
oajo.commons.FileIOUtils$BurnOnCloseFileIterator#,(Lorg/apache/commons/io/LineIterator;Lcom/google/common/base/Function;)V
[jira] [Commented] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841259#comment-16841259
]
Alex Deparvu commented on OAK-7217:
---
Hit a bottleneck with the bash approach, so I decided to build a proper
dependency analyzer: [wip
branch|https://github.com/stillalex/jackrabbit-oak/tree/foreing-apis].
The report can be generated under {{oak-run}}.
This is what I have so far. the output is a bit raw, but readable, it includes
and public method/variable from an exported package that receives/returns
objects that are not Oak or jdk.
* oak-run-commons
* oak-core
**
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder#property,(Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Ljava/lang/String;Lcom/google/common/base/Predicate;)Lorg/apache/jackrabbit/oak/plugins/observation/filter/FilterBuilder$Condition;
**
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder#universal,(Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Lcom/google/common/base/Predicate;)Lorg/apache/jackrabbit/oak/plugins/observation/filter/FilterBuilder$Condition;
**
org.apache.jackrabbit.oak.plugins.observation.filter.UniversalFilter#,(Lorg/apache/jackrabbit/oak/spi/state/NodeState;Lorg/apache/jackrabbit/oak/spi/state/NodeState;Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Lcom/google/common/base/Predicate;)V
**
org.apache.jackrabbit.oak.plugins.observation.filter.PropertyPredicate#,(Ljava/lang/String;Lcom/google/common/base/Predicate;)V
**
org.apache.jackrabbit.oak.plugins.observation.filter.FilterBuilder$UniversalCondition#,(Lorg/apache/jackrabbit/oak/plugins/observation/filter/UniversalFilter$Selector;Lcom/google/common/base/Predicate;)V
**
org.apache.jackrabbit.oak.plugins.migration.report.LoggingReporter#,(Lorg/slf4j/Logger;II)V
**
org.apache.jackrabbit.oak.plugins.migration.report.LoggingReporter#,(Lorg/slf4j/Logger;Ljava/lang/String;II)V
**
org.apache.jackrabbit.oak.plugins.index.AsyncIndexerService#activate,(Lorg/osgi/framework/BundleContext;Lorg/apache/jackrabbit/oak/plugins/index/AsyncIndexerService$Configuration;)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.IndexStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.IndexStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.UniqueEntryStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.UniqueEntryStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.FilteringIndexStoreStrategy#,(Lorg/apache/jackrabbit/oak/plugins/index/property/strategy/IndexStoreStrategy;Lcom/google/common/base/Predicate;)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.FilteringIndexStoreStrategy#,(Lorg/apache/jackrabbit/oak/plugins/index/property/strategy/IndexStoreStrategy;Lcom/google/common/base/Predicate;Z)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.FilteringIndexStoreStrategy#update,(Lcom/google/common/base/Supplier;Ljava/lang/String;Ljava/lang/String;Lorg/apache/jackrabbit/oak/spi/state/NodeBuilder;Ljava/util/Set;Ljava/util/Set;)V
**
org.apache.jackrabbit.oak.plugins.index.property.strategy.FilteringIndexStoreStrategy#exists,(Lcom/google/common/base/Supplier;Ljava/lang/String;)Z
* oak-store-composite
**
org.apache.jackrabbit.oak.composite.CompositeNodeStoreService#activate,(Lorg/osgi/service/component/ComponentContext;Ljava/util/Map;)V
**
org.apache.jackrabbit.oak.composite.checks.NodeTypeMountedNodeStoreChecker#activate,(Lorg/osgi/service/component/ComponentContext;)V
* oak-segment-azure
* oak-jcr
* oak-store-spi
**
org.apache.jackrabbit.oak.spi.state.RevisionGC#,(Ljava/lang/Runnable;Ljava/lang/Runnable;Lcom/google/common/base/Supplier;Ljava/util/concurrent/Executor;)V
**
org.apache.jackrabbit.oak.spi.state.NodeState#EXISTS,Lcom/google/common/base/Predicate;
**
org.apache.jackrabbit.oak.spi.state.ChildNodeEntry#GET_NAME,Lcom/google/common/base/Function;
**
[jira] [Commented] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840283#comment-16840283 ] Alex Deparvu commented on OAK-7217: --- Based on the above manual exports I took a look at oak-commons and it seems there are only 2 classes that have the Guava export problem: * oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/FileIOUtils.java * oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/io/LazyInputStream.java Continuing this analysis means manually going through all usages and trying to figure out if they are considered legal or not. Is this useful, or do we need a more automated approach, something that could eventually be included in a CI job? > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public-v2.log, guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838660#comment-16838660
]
Alex Deparvu edited comment on OAK-7217 at 5/15/19 10:27 AM:
-
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
[edit]
tldr; Attached a better version of the intersection: [^guava-public-v2.log].
I just realized that this will only catch packages exported in the pom.xml,
which is not the case for {{oak-commons}} for example. So I did another pass
through the exports to correct the output manually and it turns out it wasn't
too far off. there was only oak-auth-external, oak-commons, oak-store-composite
that had nothing specified in the pom.xml file.
Modules analyzed:
- oak-auth-external (below public packages not listed in pom.xml)
--
org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1
--
org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2
- oak-authorization-cug
- oak-authorization-principalbased
- oak-blob-cloud-azure
- oak-blob-cloud
-- exports a package that doesn't exist
'org.apache.jackrabbit.oak.blob.cloud.aws.s3'
- oak-blob-plugins
- oak-blob
- oak-commons (below public packages not listed in pom.xml)
-- org.apache.jackrabbit.oak.commons,version=1.3.0
-- org.apache.jackrabbit.oak.commons.cache,version=1.0.0
-- org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1
-- org.apache.jackrabbit.oak.commons.io,version=1.0.0
-- org.apache.jackrabbit.oak.commons.json,version=1.0.1
-- org.apache.jackrabbit.oak.commons.sort,version=1.0.1
- oak-core-spi
- oak-core
- oak-jcr
- oak-lucene
-- also exports all of org.apache.lucene
- oak-query-spi
- oak-search
- oak-security-spi
- oak-segment-azure
- oak-segment-tar
- oak-solr-core
- oak-solr-osgi
- oak-store-composite (below public packages not listed in pom.xml)
-- org.apache.jackrabbit.oak.composite,version=0.3.0
-- org.apache.jackrabbit.oak.composite.checks,version=0.0.0
- oak-store-document
- oak-store-spi
was (Author: alex.parvulescu):
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
[edit] just realised that this will only catch packages exported in the
pom.xml, which is not the case for {{oak-commons}} for example.
I did another pass through the exports to correct the output manually and it
turns out it wasn't too far off. there was only oak-auth-external, oak-commons,
oak-store-composite that had nothing specified in the pom.xml file. Attached a
new version of the intersection: [^guava-public-v2.log].
Modules analyzed:
- oak-auth-external (below public packages not listed in pom.xml)
--
org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1
--
org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2
- oak-authorization-cug
- oak-authorization-principalbased
- oak-blob-cloud-azure
- oak-blob-cloud
-- exports a package that doesn't exist
'org.apache.jackrabbit.oak.blob.cloud.aws.s3'
- oak-blob-plugins
- oak-blob
- oak-commons (below public packages not listed in pom.xml)
-- org.apache.jackrabbit.oak.commons,version=1.3.0
-- org.apache.jackrabbit.oak.commons.cache,version=1.0.0
-- org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1
-- org.apache.jackrabbit.oak.commons.io,version=1.0.0
-- org.apache.jackrabbit.oak.commons.json,version=1.0.1
--
[jira] [Issue Comment Deleted] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7217: -- Comment: was deleted (was: I did another pass through the exports to correct the output manually and it turns out it wasn't too far off. there was only oak-auth-external, oak-commons, oak-store-composite that had nothing specified in the pom.xml file. Attached a new version of the intersection: [^guava-public-v2.log]. Modules analyzed: - oak-auth-external -- org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1 -- org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2 - oak-authorization-cug - oak-authorization-principalbased - oak-blob-cloud-azure - oak-blob-cloud -- exports a package that doesn't exist 'org.apache.jackrabbit.oak.blob.cloud.aws.s3' - oak-blob-plugins - oak-blob - oak-commons -- org.apache.jackrabbit.oak.commons,version=1.3.0 -- org.apache.jackrabbit.oak.commons.cache,version=1.0.0 -- org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1 -- org.apache.jackrabbit.oak.commons.io,version=1.0.0 -- org.apache.jackrabbit.oak.commons.json,version=1.0.1 -- org.apache.jackrabbit.oak.commons.sort,version=1.0.1 - oak-core-spi - oak-core - oak-jcr - oak-lucene -- also exports all of org.apache.lucene - oak-query-spi - oak-search - oak-security-spi - oak-segment-azure - oak-segment-tar - oak-solr-core - oak-solr-osgi - oak-store-composite -- org.apache.jackrabbit.oak.composite,version=0.3.0 -- org.apache.jackrabbit.oak.composite.checks,version=0.0.0 - oak-store-document - oak-store-spi If I read it correctly 'oak-auth-ldap' uses guava in a single test so we could move the dependency to 'test' scope, but this is outside of this scope.) > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public-v2.log, guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838660#comment-16838660
]
Alex Deparvu edited comment on OAK-7217 at 5/15/19 10:26 AM:
-
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
[edit] just realised that this will only catch packages exported in the
pom.xml, which is not the case for {{oak-commons}} for example.
I did another pass through the exports to correct the output manually and it
turns out it wasn't too far off. there was only oak-auth-external, oak-commons,
oak-store-composite that had nothing specified in the pom.xml file. Attached a
new version of the intersection: [^guava-public-v2.log].
Modules analyzed:
- oak-auth-external (below public packages not listed in pom.xml)
--
org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1
--
org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2
- oak-authorization-cug
- oak-authorization-principalbased
- oak-blob-cloud-azure
- oak-blob-cloud
-- exports a package that doesn't exist
'org.apache.jackrabbit.oak.blob.cloud.aws.s3'
- oak-blob-plugins
- oak-blob
- oak-commons (below public packages not listed in pom.xml)
-- org.apache.jackrabbit.oak.commons,version=1.3.0
-- org.apache.jackrabbit.oak.commons.cache,version=1.0.0
-- org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1
-- org.apache.jackrabbit.oak.commons.io,version=1.0.0
-- org.apache.jackrabbit.oak.commons.json,version=1.0.1
-- org.apache.jackrabbit.oak.commons.sort,version=1.0.1
- oak-core-spi
- oak-core
- oak-jcr
- oak-lucene
-- also exports all of org.apache.lucene
- oak-query-spi
- oak-search
- oak-security-spi
- oak-segment-azure
- oak-segment-tar
- oak-solr-core
- oak-solr-osgi
- oak-store-composite (below public packages not listed in pom.xml)
-- org.apache.jackrabbit.oak.composite,version=0.3.0
-- org.apache.jackrabbit.oak.composite.checks,version=0.0.0
- oak-store-document
- oak-store-spi
was (Author: alex.parvulescu):
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
does this cover it?
[edit] just realised that this will only catch packages exported in the
pom.xml, which is not the case for {{oak-commons}} for example.
> check public Oak APIs for references to Guava
> -
>
> Key: OAK-7217
> URL: https://issues.apache.org/jira/browse/OAK-7217
> Project: Jackrabbit Oak
> Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: detect-api.diff, extract-guava.sh, guava-global.log,
> guava-public-v2.log, guava-public.log
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8034) javadoc:aggregate fails with JDK 11
[
https://issues.apache.org/jira/browse/OAK-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839328#comment-16839328
]
Alex Deparvu edited comment on OAK-8034 at 5/14/19 11:31 AM:
-
latest update using
{code}
java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
{code}
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:aggregate (default-cli) on
project jackrabbit-oak: An error has occurred in Javadoc report generation:
[ERROR] Exit code: 1 -
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/GroupPrincipals.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalProvider.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/GroupPrincipalWrapper.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/EmptyPrincipalProvider.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:145:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermDocs;
[ERROR] ^
[ERROR] symbol: class TermDocs
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:146:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermEnum;
[ERROR] ^
[ERROR] symbol: class TermEnum
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/OakAnalyzer.java:25:
error: cannot find symbol
[ERROR] import org.apache.lucene.analysis.standard.StandardTokenizer;
[ERROR] ^
[ERROR] symbol: class StandardTokenizer
[ERROR] location: package org.apache.lucene.analysis.standard
[ERROR]
oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/OakWordTokenFilter.java:22:
error: cannot find symbol
[ERROR] import org.apache.lucene.analysis.standard.StandardTokenizer;
[ERROR] ^
[ERROR] symbol: class StandardTokenizer
[ERROR] location: package org.apache.lucene.analysis.standard
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:391:
error: type ServiceTracker does not take parameters
[ERROR] private static class RepositoryTracker extends
ServiceTracker {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:409:
error: type ServiceReference does not take parameters
[ERROR] public Repository addingService(ServiceReference
reference) {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:46:
error: type ServiceTracker does not take parameters
[ERROR] class ConfigTracker extends ServiceTracker {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public ConfigurationAdmin
addingService(ServiceReference reference) {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/RunnableJobTracker.java:40:
[jira] [Commented] (OAK-8034) javadoc:aggregate fails with JDK 11
[
https://issues.apache.org/jira/browse/OAK-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839328#comment-16839328
]
Alex Deparvu commented on OAK-8034:
---
latest update using
{code}
java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
{code}
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:aggregate (default-cli) on
project jackrabbit-oak: An error has occurred in Javadoc report generation:
[ERROR] Exit code: 1 -
/Users/aparvule/work/oak/oak-live/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/GroupPrincipals.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalProvider.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/GroupPrincipalWrapper.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/EmptyPrincipalProvider.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.java:20:
warning: [removal] Group in java.security.acl has been deprecated and marked
for removal
[ERROR] import java.security.acl.Group;
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:145:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermDocs;
[ERROR] ^
[ERROR] symbol: class TermDocs
[ERROR] location: package org.apache.lucene.index
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:146:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermEnum;
[ERROR] ^
[ERROR] symbol: class TermEnum
[ERROR] location: package org.apache.lucene.index
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/OakAnalyzer.java:25:
error: cannot find symbol
[ERROR] import org.apache.lucene.analysis.standard.StandardTokenizer;
[ERROR] ^
[ERROR] symbol: class StandardTokenizer
[ERROR] location: package org.apache.lucene.analysis.standard
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/OakWordTokenFilter.java:22:
error: cannot find symbol
[ERROR] import org.apache.lucene.analysis.standard.StandardTokenizer;
[ERROR] ^
[ERROR] symbol: class StandardTokenizer
[ERROR] location: package org.apache.lucene.analysis.standard
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:391:
error: type ServiceTracker does not take parameters
[ERROR] private static class RepositoryTracker extends
ServiceTracker {
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:409:
error: type ServiceReference does not take parameters
[ERROR] public Repository addingService(ServiceReference
reference) {
[ERROR] ^
[ERROR]
/Users/aparvule/work/oak/oak-live/oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:46:
error: type ServiceTracker does not take parameters
[ERROR] class ConfigTracker extends ServiceTracker {
[ERROR] ^
[ERROR]
[jira] [Resolved] (OAK-8242) JavaDoc error in oak-authorization-principalbased
[
https://issues.apache.org/jira/browse/OAK-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-8242.
---
Resolution: Duplicate
fixed via OAK-8190
(https://issues.apache.org/jira/browse/OAK-8190?focusedCommentId=16826893=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16826893)
> JavaDoc error in oak-authorization-principalbased
> -
>
> Key: OAK-8242
> URL: https://issues.apache.org/jira/browse/OAK-8242
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Reporter: Marcel Reutegger
>Priority: Minor
>
> Building JavaDoc in oak-authorization-principalbased with {{mvn
> javadoc:javadoc}} fails with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:javadoc (default-cli) on
> project oak-authorization-principalbased: An error has occurred in Javadoc
> report generation:
> [ERROR] Exit code: 1 -
> /Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/FilterProvider.java:35:
> error: @param name not found
> [ERROR] * @param absPath The absolute oak path to be tested.
> [ERROR] ^
> [ERROR]
> /Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/FilterProvider.java:38:
> warning: no @param for oakPath
> [ERROR] boolean handlesPath(@NotNull String oakPath);
> [ERROR] ^
> [ERROR]
> /Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/impl/FilterProviderImpl.java:47:
> error: reference not found
> [ERROR] * Implementation of the {@link
> org.apache.jackrabbit.spi.security.authorization.principalbased.Filter}
> interface that
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/../bin/javadoc
> @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/target/site/apidocs'
> dir.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839155#comment-16839155 ] Alex Deparvu edited comment on OAK-7217 at 5/14/19 7:01 AM: I did another pass through the exports to correct the output manually and it turns out it wasn't too far off. there was only oak-auth-external, oak-commons, oak-store-composite that had nothing specified in the pom.xml file. Attached a new version of the intersection: [^guava-public-v2.log]. Modules analyzed: - oak-auth-external -- org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1 -- org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2 - oak-authorization-cug - oak-authorization-principalbased - oak-blob-cloud-azure - oak-blob-cloud -- exports a package that doesn't exist 'org.apache.jackrabbit.oak.blob.cloud.aws.s3' - oak-blob-plugins - oak-blob - oak-commons -- org.apache.jackrabbit.oak.commons,version=1.3.0 -- org.apache.jackrabbit.oak.commons.cache,version=1.0.0 -- org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1 -- org.apache.jackrabbit.oak.commons.io,version=1.0.0 -- org.apache.jackrabbit.oak.commons.json,version=1.0.1 -- org.apache.jackrabbit.oak.commons.sort,version=1.0.1 - oak-core-spi - oak-core - oak-jcr - oak-lucene -- also exports all of org.apache.lucene - oak-query-spi - oak-search - oak-security-spi - oak-segment-azure - oak-segment-tar - oak-solr-core - oak-solr-osgi - oak-store-composite -- org.apache.jackrabbit.oak.composite,version=0.3.0 -- org.apache.jackrabbit.oak.composite.checks,version=0.0.0 - oak-store-document - oak-store-spi If I read it correctly 'oak-auth-ldap' uses guava in a single test so we could move the dependency to 'test' scope, but this is outside of this scope. was (Author: alex.parvulescu): I did another pass through the exports to correct the output manually and it turns out it wasn't too far off. there was only oak-auth-external, oak-commons, oak-store-composite that had nothing specified in the pom.xml file. Attached a new version of the intersection: [^guava-public-v2.log]. Modules analyzed: - oak-auth-external org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1 org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2 - oak-authorization-cug - oak-authorization-principalbased - oak-blob-cloud-azure - oak-blob-cloud ? exports a package that doesn't exist 'org.apache.jackrabbit.oak.blob.cloud.aws.s3' - oak-blob-plugins - oak-blob - oak-commons org.apache.jackrabbit.oak.commons,version=1.3.0 org.apache.jackrabbit.oak.commons.cache,version=1.0.0 org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1 org.apache.jackrabbit.oak.commons.io,version=1.0.0 org.apache.jackrabbit.oak.commons.json,version=1.0.1 org.apache.jackrabbit.oak.commons.sort,version=1.0.1 - oak-core-spi - oak-core - oak-jcr - oak-lucene also exports all of org.apache.lucene - oak-query-spi - oak-search - oak-security-spi - oak-segment-azure - oak-segment-tar - oak-solr-core - oak-solr-osgi - oak-store-composite org.apache.jackrabbit.oak.composite,version=0.3.0 org.apache.jackrabbit.oak.composite.checks,version=0.0.0 - oak-store-document - oak-store-spi If I read it correctly 'oak-auth-ldap' uses guava in a single test so we could move the dependency to 'test' scope, but this is outside of this scope. > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public-v2.log, guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839155#comment-16839155 ] Alex Deparvu commented on OAK-7217: --- I did another pass through the exports to correct the output manually and it turns out it wasn't too far off. there was only oak-auth-external, oak-commons, oak-store-composite that had nothing specified in the pom.xml file. Attached a new version of the intersection: [^guava-public-v2.log]. Modules analyzed: - oak-auth-external org.apache.jackrabbit.oak.spi.security.authentication.external,version=2.3.1 org.apache.jackrabbit.oak.spi.security.authentication.external.basic,version=1.3.2 - oak-authorization-cug - oak-authorization-principalbased - oak-blob-cloud-azure - oak-blob-cloud ? exports a package that doesn't exist 'org.apache.jackrabbit.oak.blob.cloud.aws.s3' - oak-blob-plugins - oak-blob - oak-commons org.apache.jackrabbit.oak.commons,version=1.3.0 org.apache.jackrabbit.oak.commons.cache,version=1.0.0 org.apache.jackrabbit.oak.commons.concurrent,version=1.0.1 org.apache.jackrabbit.oak.commons.io,version=1.0.0 org.apache.jackrabbit.oak.commons.json,version=1.0.1 org.apache.jackrabbit.oak.commons.sort,version=1.0.1 - oak-core-spi - oak-core - oak-jcr - oak-lucene also exports all of org.apache.lucene - oak-query-spi - oak-search - oak-security-spi - oak-segment-azure - oak-segment-tar - oak-solr-core - oak-solr-osgi - oak-store-composite org.apache.jackrabbit.oak.composite,version=0.3.0 org.apache.jackrabbit.oak.composite.checks,version=0.0.0 - oak-store-document - oak-store-spi If I read it correctly 'oak-auth-ldap' uses guava in a single test so we could move the dependency to 'test' scope, but this is outside of this scope. > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public-v2.log, guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7217: -- Attachment: guava-public-v2.log > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public-v2.log, guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838660#comment-16838660
]
Alex Deparvu edited comment on OAK-7217 at 5/13/19 4:27 PM:
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
does this cover it?
[edit] just realised that this will only catch packages exported in the
pom.xml, which is not the case for {{oak-commons}} for example.
was (Author: alex.parvulescu):
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
does this cover it?
> check public Oak APIs for references to Guava
> -
>
> Key: OAK-7217
> URL: https://issues.apache.org/jira/browse/OAK-7217
> Project: Jackrabbit Oak
> Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: detect-api.diff, extract-guava.sh, guava-global.log,
> guava-public.log
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838660#comment-16838660
]
Alex Deparvu edited comment on OAK-7217 at 5/13/19 4:21 PM:
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
{noformat}
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
{noformat}
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
does this cover it?
was (Author: alex.parvulescu):
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
bq.
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
bq.
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
does this cover it?
> check public Oak APIs for references to Guava
> -
>
> Key: OAK-7217
> URL: https://issues.apache.org/jira/browse/OAK-7217
> Project: Jackrabbit Oak
> Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: detect-api.diff, extract-guava.sh, guava-global.log,
> guava-public.log
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7217) check public Oak APIs for references to Guava
[
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838660#comment-16838660
]
Alex Deparvu edited comment on OAK-7217 at 5/13/19 4:21 PM:
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
bq.
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
bq.
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
this is how I had the global usage:
{code}
grep -Rw . -e 'import\( static\)\? com.google.common' --include=\*.java | grep
-v '/src/test/' | sort
{code}
does this cover it?
was (Author: alex.parvulescu):
I tried a different approach (bash script see [^extract-guava.sh]), it wasn't
obvious but I think I was able to collect usages of Guava.
There are 2 sets attached:
* complete usage set [^guava-global.log]
* only public packages set [^guava-public.log]
Format is class and import (both normal import and static imports are captured)
bq.
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
com.google.common.base.Strings;
bq.
oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import
static com.google.common.collect.Iterables.contains;
does this cover it?
> check public Oak APIs for references to Guava
> -
>
> Key: OAK-7217
> URL: https://issues.apache.org/jira/browse/OAK-7217
> Project: Jackrabbit Oak
> Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: detect-api.diff, extract-guava.sh, guava-global.log,
> guava-public.log
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838660#comment-16838660 ] Alex Deparvu commented on OAK-7217: --- I tried a different approach (bash script see [^extract-guava.sh]), it wasn't obvious but I think I was able to collect usages of Guava. There are 2 sets attached: * complete usage set [^guava-global.log] * only public packages set [^guava-public.log] Format is class and import (both normal import and static imports are captured) bq. oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import com.google.common.base.Strings; bq. oak-security-spi/src/main/java/org/apache/jackrabbit/oak/plugins/tree/TreeUtil.java:import static com.google.common.collect.Iterables.contains; does this cover it? > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7217: -- Attachment: guava-public.log > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7217: -- Attachment: guava-global.log > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh, guava-global.log, > guava-public.log > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7217) check public Oak APIs for references to Guava
[ https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7217: -- Attachment: extract-guava.sh > check public Oak APIs for references to Guava > - > > Key: OAK-7217 > URL: https://issues.apache.org/jira/browse/OAK-7217 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Minor > Attachments: detect-api.diff, extract-guava.sh > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8303) Build failure: timeout
[ https://issues.apache.org/jira/browse/OAK-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8303. --- Resolution: Cannot Reproduce seems the issue went away > Build failure: timeout > -- > > Key: OAK-8303 > URL: https://issues.apache.org/jira/browse/OAK-8303 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > bq. Build timed out (after 120 minutes). Marking the build as failed. > The build Jackrabbit Oak #2136 has failed. > First failed run: [Jackrabbit Oak > #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] > bq. Building remotely on H28 (ubuntu xenial) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8304) VersionablePathHook: Diff.setVersionablePath never results in CommitFailedException
[
https://issues.apache.org/jira/browse/OAK-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836201#comment-16836201
]
Alex Deparvu commented on OAK-8304:
---
+1 looks good to me
> VersionablePathHook: Diff.setVersionablePath never results in
> CommitFailedException
> ---
>
> Key: OAK-8304
> URL: https://issues.apache.org/jira/browse/OAK-8304
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-8304.patch
>
>
> I tried to come up with a test case that would result in the
> {{VersionablePathHook}} running into a {{CommitFailedException}} upon
> accessing the version history and found out that this will never occur. In
> other words, the whole logic to collection {{CommitFailedException}} in
> {{VersionablePathHook}} is redundant.
> What I found was that {{ReadWriteVersionManager.getOrCreateVersionHistory}}
> is defined to potentially throw the exception on calling {{createVersion}},
> which is only triggered if the version history node contains no
> {{jcr:rootVersion}} child. However, {{createVersion}} will never throw
> {{CommitFailedException}} if the root version is created as the exception may
> only occur upon populating the {{jcr:frozenNode}}.
> Long story short: introducing {{ReadWriteVersionManager.createRootVersion}}
> and calling it from {{getOrCreateVersionHistory}} would simplify
> {{createVersion}}, make the exception declaration redundant and spare us the
> unused but prominent exception handling code in {{VersionablePathHook}}.
> [~stillalex], [~mreutegg], i would appreciate if you could review the
> proposed changes to {{VersionablePathHook}} and {{ReadWriteVersionManager}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8292) Test failure: JsonConfigRepFactoryTest and TokenAuthenticationTest
[
https://issues.apache.org/jira/browse/OAK-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831590#comment-16831590
]
Alex Deparvu edited comment on OAK-8292 at 5/8/19 4:58 PM:
---
Build is still failing.
Failed run: [Jackrabbit Oak
#2125|https://builds.apache.org/job/Jackrabbit%20Oak/2125/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/2125/console]
Different test failing:
{noformat}
org.apache.jackrabbit.oak.segment.standby.ExternalSharedStoreIT.testProxyFlippedIntermediateByte2
Failing for the past 1 build (Since Failed#2125 )
Took 0.46 sec.
Error Message
Address already in use
Stacktrace
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at
io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:128)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:554)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1266)
at
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:501)
at
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:486)
at
io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:988)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:250)
at
io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:365)
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)
at
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was (Author: hudson):
Build is still failing.
Failed run: [Jackrabbit Oak
#2125|https://builds.apache.org/job/Jackrabbit%20Oak/2125/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/2125/console]
> Test failure: JsonConfigRepFactoryTest and TokenAuthenticationTest
> --
>
> Key: OAK-8292
> URL: https://issues.apache.org/jira/browse/OAK-8292
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> Test Result (2 failures / +2)
> *
> org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar
> {noformat}
> Caused by: org.osgi.framework.BundleException: Timed out while waiting for
> repository shutdown for 60 secs
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.shutdown(OakOSGiRepositoryFactory.java:281)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryTracker.shutdownRepository(OakOSGiRepositoryFactory.java:443)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryProxy.invoke(OakOSGiRepositoryFactory.java:475)
> ... 33 more
> {noformat}
> *
> org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth
> {noformat}
> Caused by: javax.security.auth.login.LoginException: Login Failure: all
> modules ignored
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:906)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:163)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:282)
> ... 41 more
> {noformat}
> The build Jackrabbit Oak #2124 has failed.
> First failed run: [Jackrabbit Oak
> #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8292) Test failure: JsonConfigRepFactoryTest and TokenAuthenticationTest
[
https://issues.apache.org/jira/browse/OAK-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8292:
--
Summary: Test failure: JsonConfigRepFactoryTest and TokenAuthenticationTest
(was: Test failure: )
> Test failure: JsonConfigRepFactoryTest and TokenAuthenticationTest
> --
>
> Key: OAK-8292
> URL: https://issues.apache.org/jira/browse/OAK-8292
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> Test Result (2 failures / +2)
> *
> org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar
> {noformat}
> Caused by: org.osgi.framework.BundleException: Timed out while waiting for
> repository shutdown for 60 secs
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.shutdown(OakOSGiRepositoryFactory.java:281)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryTracker.shutdownRepository(OakOSGiRepositoryFactory.java:443)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryProxy.invoke(OakOSGiRepositoryFactory.java:475)
> ... 33 more
> {noformat}
> *
> org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth
> {noformat}
> Caused by: javax.security.auth.login.LoginException: Login Failure: all
> modules ignored
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:906)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:163)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:282)
> ... 41 more
> {noformat}
> The build Jackrabbit Oak #2124 has failed.
> First failed run: [Jackrabbit Oak
> #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8292) Test failure:
[
https://issues.apache.org/jira/browse/OAK-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8292:
--
Summary: Test failure: (was: Build Jackrabbit Oak #2124 failed)
> Test failure:
> --
>
> Key: OAK-8292
> URL: https://issues.apache.org/jira/browse/OAK-8292
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> Test Result (2 failures / +2)
> *
> org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar
> {noformat}
> Caused by: org.osgi.framework.BundleException: Timed out while waiting for
> repository shutdown for 60 secs
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.shutdown(OakOSGiRepositoryFactory.java:281)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryTracker.shutdownRepository(OakOSGiRepositoryFactory.java:443)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryProxy.invoke(OakOSGiRepositoryFactory.java:475)
> ... 33 more
> {noformat}
> *
> org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth
> {noformat}
> Caused by: javax.security.auth.login.LoginException: Login Failure: all
> modules ignored
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:906)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:163)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:282)
> ... 41 more
> {noformat}
> The build Jackrabbit Oak #2124 has failed.
> First failed run: [Jackrabbit Oak
> #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8302) Build failure: Failed to execute goal spotbugs on project oak-benchmarks
[ https://issues.apache.org/jira/browse/OAK-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8302: -- Summary: Build failure: Failed to execute goal spotbugs on project oak-benchmarks (was: Build Jackrabbit Oak #2134 failed) > Build failure: Failed to execute goal spotbugs on project oak-benchmarks > > > Key: OAK-8302 > URL: https://issues.apache.org/jira/browse/OAK-8302 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2134 has failed. > First failed run: [Jackrabbit Oak > #2134|https://builds.apache.org/job/Jackrabbit%20Oak/2134/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2134/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8303) Build failure: timeout
[ https://issues.apache.org/jira/browse/OAK-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8303: -- Description: bq. Build timed out (after 120 minutes). Marking the build as failed. The build Jackrabbit Oak #2136 has failed. First failed run: [Jackrabbit Oak #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] bq. Building remotely on H28 (ubuntu xenial) was: bq. Build timed out (after 120 minutes). Marking the build as failed. The build Jackrabbit Oak #2136 has failed. First failed run: [Jackrabbit Oak #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] > Build failure: timeout > -- > > Key: OAK-8303 > URL: https://issues.apache.org/jira/browse/OAK-8303 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > bq. Build timed out (after 120 minutes). Marking the build as failed. > The build Jackrabbit Oak #2136 has failed. > First failed run: [Jackrabbit Oak > #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] > bq. Building remotely on H28 (ubuntu xenial) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8303) Build failure: timeout
[ https://issues.apache.org/jira/browse/OAK-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8303: -- Summary: Build failure: timeout (was: Build Jackrabbit Oak #2136 failed) > Build failure: timeout > -- > > Key: OAK-8303 > URL: https://issues.apache.org/jira/browse/OAK-8303 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > bq. Build timed out (after 120 minutes). Marking the build as failed. > The build Jackrabbit Oak #2136 has failed. > First failed run: [Jackrabbit Oak > #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8303) Build Jackrabbit Oak #2136 failed
[ https://issues.apache.org/jira/browse/OAK-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8303: -- Description: bq. Build timed out (after 120 minutes). Marking the build as failed. The build Jackrabbit Oak #2136 has failed. First failed run: [Jackrabbit Oak #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] was: No description is provided The build Jackrabbit Oak #2136 has failed. First failed run: [Jackrabbit Oak #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] > Build Jackrabbit Oak #2136 failed > - > > Key: OAK-8303 > URL: https://issues.apache.org/jira/browse/OAK-8303 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > bq. Build timed out (after 120 minutes). Marking the build as failed. > The build Jackrabbit Oak #2136 has failed. > First failed run: [Jackrabbit Oak > #2136|https://builds.apache.org/job/Jackrabbit%20Oak/2136/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2136/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8292) Build Jackrabbit Oak #2124 failed
[
https://issues.apache.org/jira/browse/OAK-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8292:
--
Description:
Test Result (2 failures / +2)
* org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar
{noformat}
Caused by: org.osgi.framework.BundleException: Timed out while waiting for
repository shutdown for 60 secs
at
org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.shutdown(OakOSGiRepositoryFactory.java:281)
at
org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryTracker.shutdownRepository(OakOSGiRepositoryFactory.java:443)
at
org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryProxy.invoke(OakOSGiRepositoryFactory.java:475)
... 33 more
{noformat}
*
org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth
{noformat}
Caused by: javax.security.auth.login.LoginException: Login Failure: all modules
ignored
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:906)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at
org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:163)
at
org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:282)
... 41 more
{noformat}
The build Jackrabbit Oak #2124 has failed.
First failed run: [Jackrabbit Oak
#2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console]
was:
No description is provided
The build Jackrabbit Oak #2124 has failed.
First failed run: [Jackrabbit Oak
#2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console]
Test Result (2 failures / +2)
* org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar
*
org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth
> Build Jackrabbit Oak #2124 failed
> -
>
> Key: OAK-8292
> URL: https://issues.apache.org/jira/browse/OAK-8292
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> Test Result (2 failures / +2)
> *
> org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar
> {noformat}
> Caused by: org.osgi.framework.BundleException: Timed out while waiting for
> repository shutdown for 60 secs
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory.shutdown(OakOSGiRepositoryFactory.java:281)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryTracker.shutdownRepository(OakOSGiRepositoryFactory.java:443)
> at
> org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactory$RepositoryProxy.invoke(OakOSGiRepositoryFactory.java:475)
> ... 33 more
> {noformat}
> *
> org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth
> {noformat}
> Caused by: javax.security.auth.login.LoginException: Login Failure: all
> modules ignored
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:906)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:163)
> at
> org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:282)
> ... 41 more
> {noformat}
> The build Jackrabbit Oak #2124 has failed.
> First failed run: [Jackrabbit Oak
> #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8292) Build Jackrabbit Oak #2124 failed
[ https://issues.apache.org/jira/browse/OAK-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8292: -- Description: No description is provided The build Jackrabbit Oak #2124 has failed. First failed run: [Jackrabbit Oak #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console] Test Result (2 failures / +2) * org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar * org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth was: No description is provided The build Jackrabbit Oak #2124 has failed. First failed run: [Jackrabbit Oak #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console] > Build Jackrabbit Oak #2124 failed > - > > Key: OAK-8292 > URL: https://issues.apache.org/jira/browse/OAK-8292 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2124 has failed. > First failed run: [Jackrabbit Oak > #2124|https://builds.apache.org/job/Jackrabbit%20Oak/2124/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2124/console] > Test Result (2 failures / +2) > * > org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar > * > org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest.tokenCreationWithPreAuth -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8260) Build Jackrabbit Oak #2102 failed
[ https://issues.apache.org/jira/browse/OAK-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8260. --- Resolution: Cannot Reproduce > Build Jackrabbit Oak #2102 failed > - > > Key: OAK-8260 > URL: https://issues.apache.org/jira/browse/OAK-8260 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2102 has failed. > First failed run: [Jackrabbit Oak > #2102|https://builds.apache.org/job/Jackrabbit%20Oak/2102/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2102/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8260) Build Jackrabbit Oak #2102 failed
[ https://issues.apache.org/jira/browse/OAK-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu closed OAK-8260. - > Build Jackrabbit Oak #2102 failed > - > > Key: OAK-8260 > URL: https://issues.apache.org/jira/browse/OAK-8260 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2102 has failed. > First failed run: [Jackrabbit Oak > #2102|https://builds.apache.org/job/Jackrabbit%20Oak/2102/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2102/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8302) Build Jackrabbit Oak #2134 failed
[
https://issues.apache.org/jira/browse/OAK-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835746#comment-16835746
]
Alex Deparvu commented on OAK-8302:
---
{noformat}
[ERROR] Failed to execute goal
com.github.spotbugs:spotbugs-maven-plugin:3.1.11:spotbugs (spotbugs) on project
oak-benchmarks: Execution spotbugs of goal
com.github.spotbugs:spotbugs-maven-plugin:3.1.11:spotbugs failed: Java
returned: 2147483647 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :oak-benchmarks
{noformat}
> Build Jackrabbit Oak #2134 failed
> -
>
> Key: OAK-8302
> URL: https://issues.apache.org/jira/browse/OAK-8302
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2134 has failed.
> First failed run: [Jackrabbit Oak
> #2134|https://builds.apache.org/job/Jackrabbit%20Oak/2134/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2134/console]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8299) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu closed OAK-8299. - > Build failure: Unable to start docker container > --- > > Key: OAK-8299 > URL: https://issues.apache.org/jira/browse/OAK-8299 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2130 has failed. > First failed run: [Jackrabbit Oak > #2130|https://builds.apache.org/job/Jackrabbit%20Oak/2130/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2130/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8299) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8299. --- Resolution: Cannot Reproduce > Build failure: Unable to start docker container > --- > > Key: OAK-8299 > URL: https://issues.apache.org/jira/browse/OAK-8299 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2130 has failed. > First failed run: [Jackrabbit Oak > #2130|https://builds.apache.org/job/Jackrabbit%20Oak/2130/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2130/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8299) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8299: -- Summary: Build failure: Unable to start docker container (was: Build Jackrabbit Oak #2130 failed) > Build failure: Unable to start docker container > --- > > Key: OAK-8299 > URL: https://issues.apache.org/jira/browse/OAK-8299 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2130 has failed. > First failed run: [Jackrabbit Oak > #2130|https://builds.apache.org/job/Jackrabbit%20Oak/2130/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2130/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8230) Build Jackrabbit Oak #2084 failed
[ https://issues.apache.org/jira/browse/OAK-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu closed OAK-8230. - > Build Jackrabbit Oak #2084 failed > - > > Key: OAK-8230 > URL: https://issues.apache.org/jira/browse/OAK-8230 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2084 has failed. > First failed run: [Jackrabbit Oak > #2084|https://builds.apache.org/job/Jackrabbit%20Oak/2084/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2084/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8253) Build Jackrabbit Oak #2097 failed
[ https://issues.apache.org/jira/browse/OAK-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu closed OAK-8253. - > Build Jackrabbit Oak #2097 failed > - > > Key: OAK-8253 > URL: https://issues.apache.org/jira/browse/OAK-8253 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2097 has failed. > First failed run: [Jackrabbit Oak > #2097|https://builds.apache.org/job/Jackrabbit%20Oak/2097/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2097/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8253) Build Jackrabbit Oak #2097 failed
[ https://issues.apache.org/jira/browse/OAK-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8253. --- Resolution: Cannot Reproduce > Build Jackrabbit Oak #2097 failed > - > > Key: OAK-8253 > URL: https://issues.apache.org/jira/browse/OAK-8253 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2097 has failed. > First failed run: [Jackrabbit Oak > #2097|https://builds.apache.org/job/Jackrabbit%20Oak/2097/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2097/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8230) Build Jackrabbit Oak #2084 failed
[ https://issues.apache.org/jira/browse/OAK-8230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8230. --- Resolution: Cannot Reproduce > Build Jackrabbit Oak #2084 failed > - > > Key: OAK-8230 > URL: https://issues.apache.org/jira/browse/OAK-8230 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2084 has failed. > First failed run: [Jackrabbit Oak > #2084|https://builds.apache.org/job/Jackrabbit%20Oak/2084/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2084/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8306:
--
Labels: (was: candidate_oak_1_10)
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.10.3, 1.14.0
>
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8306:
--
Fix Version/s: 1.10.3
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: candidate_oak_1_10
> Fix For: 1.10.3, 1.14.0
>
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835697#comment-16835697
]
Alex Deparvu edited comment on OAK-8306 at 5/8/19 4:09 PM:
---
* fixed on trunk with http://svn.apache.org/viewvc?rev=1858931=rev
* 1.10 with http://svn.apache.org/viewvc?rev=1858932=rev
was (Author: alex.parvulescu):
fixed on trunk with http://svn.apache.org/viewvc?rev=1858931=rev
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-8306.
---
Resolution: Fixed
Fix Version/s: 1.14.0
fixed on trunk with http://svn.apache.org/viewvc?rev=1858931=rev
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835657#comment-16835657
]
Alex Deparvu commented on OAK-8306:
---
bq. maybe triggering cache creation for a user without group membership
thanks. this is not possible due to the {{MEMBERSHIP_THRESHOLD}} check, it
would have to be a test that starts with a few members, then removes all of
them, so basically ending up in the current test. I'll add the jira for future
ref.
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: candidate_oak_1_10
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8306:
--
Labels: candidate_oak_1_10 (was: )
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Labels: candidate_oak_1_10
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835640#comment-16835640
]
Alex Deparvu commented on OAK-8306:
---
[~anchela] feedback appreciated!
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
[
https://issues.apache.org/jira/browse/OAK-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8306:
--
Attachment: OAK-8306.patch
> Empty PrincipalProvider cache breaks membership collection
> --
>
> Key: OAK-8306
> URL: https://issues.apache.org/jira/browse/OAK-8306
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Attachments: OAK-8306.patch
>
>
> Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
> with {{Collections.emptySet()}} forgetting that this is actually an immutable
> set.
> {noformat}
> 02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
> org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
> to authenticate null: java.lang.UnsupportedOperationExcepti
> on
> at java.util.AbstractCollection.add(AbstractCollection.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
>
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
>
> at
> org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
>
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
> {noformat}
> [0]
> https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8306) Empty PrincipalProvider cache breaks membership collection
Alex Deparvu created OAK-8306:
-
Summary: Empty PrincipalProvider cache breaks membership collection
Key: OAK-8306
URL: https://issues.apache.org/jira/browse/OAK-8306
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: Alex Deparvu
Assignee: Alex Deparvu
Regression caused by OAK-7024 [0] when I replaced {{new HashSet(1)}}
with {{Collections.emptySet()}} forgetting that this is actually an immutable
set.
{noformat}
02.05.2019 11:50:51.663 INFO [qtp1880753633-1912]
org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable
to authenticate null: java.lang.UnsupportedOperationExcepti
on
at java.util.AbstractCollection.add(AbstractCollection.java:262)
at
org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getGroupMembership(UserPrincipalProvider.java:267)
at
org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.getMembershipPrincipals(UserPrincipalProvider.java:124)
at
org.apache.jackrabbit.oak.spi.security.authentication.AbstractLoginModule.getPrincipals(AbstractLoginModule.java:498)
at
org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.commit(TokenLoginModule.java:154)
{noformat}
[0]
https://github.com/apache/jackrabbit-oak/commit/75fa2b33cc7d5447aae2ecefbf369c3b2b2c424b#diff-bca626bc7a86cf9a4435a00386f08401L322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7778) PasswordUtil#isPlainTextPassword doesn't validate PBKDF2 scheme
[ https://issues.apache.org/jira/browse/OAK-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-7778: -- Fix Version/s: 1.8.13 > PasswordUtil#isPlainTextPassword doesn't validate PBKDF2 scheme > --- > > Key: OAK-7778 > URL: https://issues.apache.org/jira/browse/OAK-7778 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.10.0, 1.9.8, 1.8.13 > > > Support for PBKDF2 was added quite a while back with OAK-697 but it seems > it's not really usable due to password validation. > PasswordUtil#isPlainTextPassword seems to think PBKDF2 is plain text, so it > will not allow any passwords to be set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7778) PasswordUtil#isPlainTextPassword doesn't validate PBKDF2 scheme
[ https://issues.apache.org/jira/browse/OAK-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834589#comment-16834589 ] Alex Deparvu commented on OAK-7778: --- backport to 1.8: http://svn.apache.org/viewvc?rev=1858836=rev > PasswordUtil#isPlainTextPassword doesn't validate PBKDF2 scheme > --- > > Key: OAK-7778 > URL: https://issues.apache.org/jira/browse/OAK-7778 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.10.0, 1.9.8, 1.8.13 > > > Support for PBKDF2 was added quite a while back with OAK-697 but it seems > it's not really usable due to password validation. > PasswordUtil#isPlainTextPassword seems to think PBKDF2 is plain text, so it > will not allow any passwords to be set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8187) Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider and RestrictionProvider
[
https://issues.apache.org/jira/browse/OAK-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833605#comment-16833605
]
Alex Deparvu commented on OAK-8187:
---
looks good to me.
> Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider
> and RestrictionProvider
> -
>
> Key: OAK-8187
> URL: https://issues.apache.org/jira/browse/OAK-8187
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-8187.patch
>
>
> The way multiple {{AuthorizableNodeName}}, {{AuthorizableActionProvider}} and
> {{RestrictionProvider}} service are handled by
> {{SecurityProviderRegistration}} suffers from the same issues as was reported
> for {{UserAuthenticationFactory}} (see OAK-8045). Once OAK-8045 is addressed
> we should adopt the same behavior for the remaining bind/unbind methods for
> the interfaces mentioned above.
> cc: [~stillalex]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8283) Make LazyValue implement Supplier
[
https://issues.apache.org/jira/browse/OAK-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-8283.
---
Resolution: Fixed
Assignee: Alex Deparvu
Fix Version/s: 1.12.1
http://svn.apache.org/viewvc?rev=1858758=rev
> Make LazyValue implement Supplier
> -
>
> Key: OAK-8283
> URL: https://issues.apache.org/jira/browse/OAK-8283
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Trivial
> Fix For: 1.12.1
>
>
> Proposal is to have {{LazyValue}} implement
> {{java.util.function.Supplier}}.
> This can be seen as the missing jdk memoizing Supplier (produces a value once
> and reuses it), very similar to {{com.google.common.base.Suppliers.memoize}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[ https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8249: -- Attachment: OAK-8249-v2.patch > NodeImpl#isNodeType could load mixin info lazily > > > Key: OAK-8249 > URL: https://issues.apache.org/jira/browse/OAK-8249 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, core-spi, jcr >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Fix For: 1.12.1 > > Attachments: OAK-8249-v2.patch > > > The current isNodeType check loads both primary type and all mixins eagerly. > I'm wondering how often is the case where someone only needs a primary type > check, and if loading the mixins lazily would improve the throughput. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[
https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-8249.
---
Resolution: Fixed
Fix Version/s: 1.12.1
Had a review with [~mreutegg] and we finally decided to not continue with the
v2 version due to risk of change to the
{{EffectiveNodeTypeProvider#isNodeType}} method.
The current implementation is subtly different than {{Node#isNodeType}} in the
case when the session doesn't have access to the {{jcr:mixinTypes}} property
and changing it would introduce a possible regression for all callers (internal
and external).
I also updated the patch with a javadoc note to {{EffectiveNodeTypeProvider}}
mentioning this difference in implementations.
Re. callers of the api, we decided it will be a good (and probably interesting)
exercise to review all calls of this method from other oak bundles as there
seem to be a few of them around.
Thanks [~mreutegg] for the help.
Fixed with http://svn.apache.org/viewvc?rev=1858530=rev
> NodeImpl#isNodeType could load mixin info lazily
>
>
> Key: OAK-8249
> URL: https://issues.apache.org/jira/browse/OAK-8249
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, core-spi, jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
> Fix For: 1.12.1
>
>
> The current isNodeType check loads both primary type and all mixins eagerly.
> I'm wondering how often is the case where someone only needs a primary type
> check, and if loading the mixins lazily would improve the throughput.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8283) Make LazyValue implement Supplier
Alex Deparvu created OAK-8283:
-
Summary: Make LazyValue implement Supplier
Key: OAK-8283
URL: https://issues.apache.org/jira/browse/OAK-8283
Project: Jackrabbit Oak
Issue Type: Improvement
Components: commons
Reporter: Alex Deparvu
Proposal is to have {{LazyValue}} implement
{{java.util.function.Supplier}}.
This can be seen as the missing jdk memoizing Supplier (produces a value once
and reuses it), very similar to {{com.google.common.base.Suppliers.memoize}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[
https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826921#comment-16826921
]
Alex Deparvu commented on OAK-8249:
---
I restarted clean from trunk and focused on fixing the
{{ReadOnlyNodeTypeManager}} directly. this is what I have [0].
It's a better approach, as we're fixing the core issue, but the code doesn't
look too clean due to the awkwardness of providing the missing pieces to the
{{ReadOnlyNodeTypeManager}} class. I'm curious to see if there's something I
missed.
As I sidenote, I had to remove some optimisations because tests from
ReadNodeTypeTest (OAK-3775) were failing [1]. It might actually be better to
have a consistent behavior here, and the NodeImpl version is probably better.
[0]
https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8249-v2
[1]
https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8249-v2#diff-c48ef6caa98b019abda9bf4b5ec5a8e7L257
> NodeImpl#isNodeType could load mixin info lazily
>
>
> Key: OAK-8249
> URL: https://issues.apache.org/jira/browse/OAK-8249
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, core-spi, jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> The current isNodeType check loads both primary type and all mixins eagerly.
> I'm wondering how often is the case where someone only needs a primary type
> check, and if loading the mixins lazily would improve the throughput.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu resolved OAK-8234.
---
Resolution: Fixed
thanks for the continuous review [~anchela]!
fixed with http://svn.apache.org/viewvc?rev=1858054=rev
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.14.0
>
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8234:
--
Fix Version/s: 1.14.0
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.14.0
>
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824982#comment-16824982
]
Alex Deparvu commented on OAK-8234:
---
rebased the branch post OAK-8240 [0]. I flipped the failing test's condition to
true to reflect admin session behavior.
[~anchela] how is it looking?
[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8234
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[ https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8249: -- Component/s: core-spi core > NodeImpl#isNodeType could load mixin info lazily > > > Key: OAK-8249 > URL: https://issues.apache.org/jira/browse/OAK-8249 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, core-spi, jcr >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > > The current isNodeType check loads both primary type and all mixins eagerly. > I'm wondering how often is the case where someone only needs a primary type > check, and if loading the mixins lazily would improve the throughput. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[
https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819875#comment-16819875
]
Alex Deparvu commented on OAK-8249:
---
I have updated the wip branch [0] based on feedback so far.
Added a new method to {{EffectiveNodeTypeProvider}} that takes an Iterable,
deprecated the old one (cannot remove it due to BC concerns).
And it turns out a lot of methods did not actually throw
{{RepositoryException}}, so I updated the signatures, making for a lot cleaner
code.
Didn't update the bench numbers as delta is in the same ballpark.
bq. doesn't that mean the current implementation of
EffectiveNodeTypeProvider.isNodeType(Tree, String) is incorrect then?
Yes I agree this looks fishy. Taking into consideration OAK-7652 and OAK-7997
this part might have been an oversight.
I will try to clarify this next but will create a dedicated issue to not mix
things too much.
[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8249
> NodeImpl#isNodeType could load mixin info lazily
>
>
> Key: OAK-8249
> URL: https://issues.apache.org/jira/browse/OAK-8249
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> The current isNodeType check loads both primary type and all mixins eagerly.
> I'm wondering how often is the case where someone only needs a primary type
> check, and if loading the mixins lazily would improve the throughput.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[
https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819102#comment-16819102
]
Alex Deparvu commented on OAK-8249:
---
Yeah, that would have already been optimized, but I don't think it takes into
account everything that is happening in {{NodeImpl#getMixinTypeNames}}.
> NodeImpl#isNodeType could load mixin info lazily
>
>
> Key: OAK-8249
> URL: https://issues.apache.org/jira/browse/OAK-8249
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> The current isNodeType check loads both primary type and all mixins eagerly.
> I'm wondering how often is the case where someone only needs a primary type
> check, and if loading the mixins lazily would improve the throughput.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[ https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819086#comment-16819086 ] Alex Deparvu commented on OAK-8249: --- yeah of course, but I'm not sure how easy this switch might be. > NodeImpl#isNodeType could load mixin info lazily > > > Key: OAK-8249 > URL: https://issues.apache.org/jira/browse/OAK-8249 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > > The current isNodeType check loads both primary type and all mixins eagerly. > I'm wondering how often is the case where someone only needs a primary type > check, and if loading the mixins lazily would improve the throughput. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[
https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819056#comment-16819056
]
Alex Deparvu commented on OAK-8249:
---
This is a wip evaluation branch [0].
preliminary benchmark results look good (almost 4x faster), but the test is
obviously biased because it only does primary type lookup. still good to get a
feel for some raw numbers:
{noformat}
(trunk)
# IsNodeTypeTest C min 10% 50% 90% max
N
Oak-Segment-Tar1 85 87 92 98 130
644
(patch)
# IsNodeTypeTest C min 10% 50% 90% max
N
Oak-Segment-Tar1 21 22 23 24 32
2590
{noformat}
Unfortunately there is an Interator<> passed around so I had to wrap into a
custom lazy loading iterator (not sure if something like this exists already,
it is generic enough to go into some sort of commons code if needed).
Problem 2: dealing with the RepositoryException from the lazy loader is a pain,
the current solution is very hacky.
[~mreutegg] what do you think?
[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8249
> NodeImpl#isNodeType could load mixin info lazily
>
>
> Key: OAK-8249
> URL: https://issues.apache.org/jira/browse/OAK-8249
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> The current isNodeType check loads both primary type and all mixins eagerly.
> I'm wondering how often is the case where someone only needs a primary type
> check, and if loading the mixins lazily would improve the throughput.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
Alex Deparvu created OAK-8249: - Summary: NodeImpl#isNodeType could load mixin info lazily Key: OAK-8249 URL: https://issues.apache.org/jira/browse/OAK-8249 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Alex Deparvu Assignee: Alex Deparvu The current isNodeType check loads both primary type and all mixins eagerly. I'm wondering how often is the case where someone only needs a primary type check, and if loading the mixins lazily would improve the throughput. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8247) Add non-admin mode for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8247: -- Labels: (was: candidate_oak_1_10) > Add non-admin mode for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8247) Add non-admin mode for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818840#comment-16818840 ] Alex Deparvu edited comment on OAK-8247 at 4/16/19 9:52 AM: * fixed on trunk http://svn.apache.org/viewvc?rev=1857635=rev * 1.10 branch http://svn.apache.org/viewvc?rev=1857636=rev was (Author: alex.parvulescu): * fixed on trunk http://svn.apache.org/viewvc?rev=1857635=rev > Add non-admin mode for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated
[ https://issues.apache.org/jira/browse/OAK-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818848#comment-16818848 ] Alex Deparvu commented on OAK-8232: --- fyi 'candidate_oak_1_12' label should not exist, as the 1.12 branch doesn't exist. > Node#setPrimaryType(String) does not create child nodes defined as autoCreated > -- > > Key: OAK-8232 > URL: https://issues.apache.org/jira/browse/OAK-8232 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.12.0 >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Labels: candidate_oak_1_12 > Fix For: 1.14.0 > > Attachments: oak-8232-testcase.patch, oak-8232.patch > > > In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does > not create child nodes that are defined as autoCreated. See attached failing > test case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8247) Add non-admin mode for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8247: -- Labels: candidate_oak_1_10 (was: candidate_oak_1_10 candidate_oak_1_12) > Add non-admin mode for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8247) Add non-admin mode for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8247. --- Resolution: Fixed * fixed on trunk http://svn.apache.org/viewvc?rev=1857635=rev > Add non-admin mode for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_12 > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8247) Add non-admin mode for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8247: -- Summary: Add non-admin mode for Node.isNodeType() benchmark (was: Add non-admin user for Node.isNodeType() benchmark) > Add non-admin mode for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_12 > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8247) Add non-admin user for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8247: -- Labels: candidate_oak_1_10 candidate_oak_1_12 (was: ) > Add non-admin user for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_12 > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8247) Add non-admin user for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818773#comment-16818773 ] Alex Deparvu edited comment on OAK-8247 at 4/16/19 8:32 AM: proposed patch [0]. [~mreutegg] could you take a quick look? admin flag is disabled by default, I'm not against switching default to 'on' if it's more suited. [0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8247. was (Author: alex.parvulescu): proposed patch [0]. [~mreutegg] could you take a quick look? [0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8247. > Add non-admin user for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8247) Add non-admin user for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8247: -- Fix Version/s: 1.14.0 > Add non-admin user for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > Fix For: 1.14.0 > > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8247) Add non-admin user for Node.isNodeType() benchmark
[ https://issues.apache.org/jira/browse/OAK-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818773#comment-16818773 ] Alex Deparvu commented on OAK-8247: --- proposed patch [0]. [~mreutegg] could you take a quick look? [0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8247. > Add non-admin user for Node.isNodeType() benchmark > -- > > Key: OAK-8247 > URL: https://issues.apache.org/jira/browse/OAK-8247 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Minor > > Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8247) Add non-admin user for Node.isNodeType() benchmark
Alex Deparvu created OAK-8247: - Summary: Add non-admin user for Node.isNodeType() benchmark Key: OAK-8247 URL: https://issues.apache.org/jira/browse/OAK-8247 Project: Jackrabbit Oak Issue Type: Improvement Components: benchmarks Reporter: Alex Deparvu Assignee: Alex Deparvu Foolowup of OAK-8205 to allow using a non admin user for the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818691#comment-16818691
]
Alex Deparvu commented on OAK-8234:
---
bq. Also: I would like the new class AllPermissionProviderImpl to come with a
dedicated test class with unit tests. Also an extra test for
AuthorizationConfigurationImpl...
sure, I'll wait for the outcome of OAK-8240 to continue working on this patch.
bq. if the distinction between administrative and non-administrative principal
set is taken care of in AuthorizationConfigurationImpl shouldn't we remove that
check then in PermissionProviderImpl? Also: isn't AllPermissions then redundant
and should be removed?
Given the current evolution of the patch (it's now completely decoupled from
the PermissionProviderImpl), I would prefer to not touch that part at all.
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817817#comment-16817817
]
Alex Deparvu edited comment on OAK-8234 at 4/15/19 10:05 AM:
-
bq. Alex Deparvu, while the intended change makes a lot of sense to me, i don't
particularly like the delegatee approach with yet another redirection. in
particular since it creates a lot of changes to the PermissionProviderImpl that
might result in subtle regressions. Is there a reason for not making the
distinction between administrative subjects and regular subjects right in the
AuthorizationConfigurationImpl? that would place that fundamental difference
between set of principals that are subjected to permission evaluation vs those
that are not prominently in the flow. also for administrative principals the
whole Mount handling is IMO redundant and which is not taken into account in
the patch as far as i saw. wdyt?
Interesting suggestion, I had not considered this but it makes more sense to
inject the admin provider directly in the {{AuthorizationConfigurationImpl}}.
I'll update the patch.
[edit] updated the patch and rebased the branch so it reads cleaner
was (Author: alex.parvulescu):
bq. Alex Deparvu, while the intended change makes a lot of sense to me, i don't
particularly like the delegatee approach with yet another redirection. in
particular since it creates a lot of changes to the PermissionProviderImpl that
might result in subtle regressions. Is there a reason for not making the
distinction between administrative subjects and regular subjects right in the
AuthorizationConfigurationImpl? that would place that fundamental difference
between set of principals that are subjected to permission evaluation vs those
that are not prominently in the flow. also for administrative principals the
whole Mount handling is IMO redundant and which is not taken into account in
the patch as far as i saw. wdyt?
Interesting suggestion, I had not considered this but it makes more sense to
inject the admin provider directly in the {{AuthorizationConfigurationImpl}}.
I'll update the patch.
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817817#comment-16817817
]
Alex Deparvu commented on OAK-8234:
---
bq. Alex Deparvu, while the intended change makes a lot of sense to me, i don't
particularly like the delegatee approach with yet another redirection. in
particular since it creates a lot of changes to the PermissionProviderImpl that
might result in subtle regressions. Is there a reason for not making the
distinction between administrative subjects and regular subjects right in the
AuthorizationConfigurationImpl? that would place that fundamental difference
between set of principals that are subjected to permission evaluation vs those
that are not prominently in the flow. also for administrative principals the
whole Mount handling is IMO redundant and which is not taken into account in
the patch as far as i saw. wdyt?
Interesting suggestion, I had not considered this but it makes more sense to
inject the admin provider directly in the {{AuthorizationConfigurationImpl}}.
I'll update the patch.
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated
[ https://issues.apache.org/jira/browse/OAK-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817642#comment-16817642 ] Alex Deparvu commented on OAK-8232: --- I think the type existence check already happens a few lines above [0], there's no need to redo it. Re. location of the code, I think parts of this should move to the NodeDelegate, but it might be simpler to keep this change focused on the bug itself and refactor later. [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/NodeImpl.java#L1357 > Node#setPrimaryType(String) does not create child nodes defined as autoCreated > -- > > Key: OAK-8232 > URL: https://issues.apache.org/jira/browse/OAK-8232 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.12.0 >Reporter: Manfred Baedke >Priority: Minor > Attachments: oak-8232-testcase.patch, oak-8232.patch > > > In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does > not create child nodes that are defined as autoCreated. See attached failing > test case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
[
https://issues.apache.org/jira/browse/OAK-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816297#comment-16816297
]
Alex Deparvu commented on OAK-8234:
---
Proposed patch [0].
In order to keep the change footprint to a minimum, I decided to turn the
{{PermissionProviderImpl}} into a wrapper that would delegate calls to the
admin allow-all version, or the existing version (copy of the current code,
renamed as {{CompiledPermissionProviderImpl}}).
As an interesting aside there's a failing test I had to mark ignore, which
deserves some discussion:
{{PermissionProviderImplTest#testIsGrantedNonExistingVersionStoreLocation}}.
Does it really matter for an admin session if that path actually exists or not?
[~anchela] what do you think?
Also, the benchmark numbers are crazy (20x improvement on
ConcurrentHasPermissionTest):
{noformat}
[trunk]
# ConcurrentHasPermissionTes C min 10% 50% 90% max
N
Import deep tree: 7359
All paths: 123545
Oak-Segment-Tar 10 5 10 64 189 742
6992
[patch]
# ConcurrentHasPermissionTes C min 10% 50% 90% max
N
Import deep tree: 6179
All paths: 123545
Oak-Segment-Tar 10 0 7 8 9 56
75327
{noformat}
[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:OAK-8234
> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin
> sessions, but we can still do better by simply not creating many of the
> objects needed as parameters for the {{CompiledPermissions}} which will be
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions
Alex Deparvu created OAK-8234:
-
Summary: Reduce object allocation in PermissionProviderImpl for
admin sessions
Key: OAK-8234
URL: https://issues.apache.org/jira/browse/OAK-8234
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Alex Deparvu
Assignee: Alex Deparvu
There was already a lot of work done here to improve efficiency of admin
sessions, but we can still do better by simply not creating many of the objects
needed as parameters for the {{CompiledPermissions}} which will be ignored
anyway in the case of admin sessions.
Ex: There are a lot of immutable trees (created via
{{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used for
the evaluation.
Thanks to [~mreutegg] for spotting this one!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8231) Unreachable code in LoginModuleImpl.getLoginId
[
https://issues.apache.org/jira/browse/OAK-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816246#comment-16816246
]
Alex Deparvu commented on OAK-8231:
---
agreed, let's remove this.
> Unreachable code in LoginModuleImpl.getLoginId
> --
>
> Key: OAK-8231
> URL: https://issues.apache.org/jira/browse/OAK-8231
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Priority: Minor
>
> [~stillalex], as discussed today it seems that the following block in
> {{LoginModuleImpl.getLoginId}} can never be reached
> {code}
>[... here if-statements for 3 types of supported credentials...]
>else {
> try {
> NameCallback callback = new NameCallback("User-ID: ");
> callbackHandler.handle(new Callback[] { callback });
> uid = callback.getName();
> } catch (IOException | UnsupportedCallbackException e) {
> onError();
> log.error(e.getMessage(), e);
> }
> }
> {code}
> the reason for this: that block resides inside an if-statement verifying that
> {{credentials}} are not null. if credentials are not null they will be any of
> the supported classes according to the implementation of {{getCredentials}},
> which will return null if none of the credentials extracted from
> subject/callback/sharedstate is supported.
> as discussed the safest way to deal with this is probably to get rid of that
> block altogether. let me know if you have any concern with that approach.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814376#comment-16814376
]
Alex Deparvu commented on OAK-8209:
---
I think the test is too weak to represent normal operations. The tree will
probably be valid as long as the NodeState will be available. If I remember
correctly from back in the day, you can get into trouble keeping a tree
reference over a compaction run (you'd start seeing SNFEs), but that might not
be true anymore. And this is of course segment store, for the document store
you are the expert :)
In general, a session will get refreshed, but a hard reference to a tree will
not, hence my suggestion to set the tree to null on {{refresh}}, does that not
fare well with the benchmark?
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814325#comment-16814325
]
Alex Deparvu commented on OAK-8209:
---
bq. The root in SessionDelegate is final. That is, the ReadWriteNodeTypeManager
can just as well remember the Tree.
I think this is not entirely correct. The delegate can call Root#rebase which
can invalidate the tree:
{noformat}
Rebase this root instance to the latest revision. After a call to this method,
trees obtained through getTree(String) may become non existing.{noformat}
I think you could work around this by setting it to null in {{refresh()}}.
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814325#comment-16814325
]
Alex Deparvu edited comment on OAK-8209 at 4/10/19 10:54 AM:
-
bq. The root in SessionDelegate is final. That is, the ReadWriteNodeTypeManager
can just as well remember the Tree.
I think this is not entirely correct. The delegate can call Root#rebase (or
Root#refresh) which can invalidate the tree:
{noformat}
Rebase this root instance to the latest revision. After a call to this method,
trees obtained through getTree(String) may become non existing.
{noformat}
I think you could work around this by setting it to null in {{refresh()}}.
was (Author: alex.parvulescu):
bq. The root in SessionDelegate is final. That is, the ReadWriteNodeTypeManager
can just as well remember the Tree.
I think this is not entirely correct. The delegate can call Root#rebase which
can invalidate the tree:
{noformat}
Rebase this root instance to the latest revision. After a call to this method,
trees obtained through getTree(String) may become non existing.{noformat}
I think you could work around this by setting it to null in {{refresh()}}.
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8157) Download page gpg example needs second parameter
[
https://issues.apache.org/jira/browse/OAK-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810767#comment-16810767
]
Alex Deparvu commented on OAK-8157:
---
right, I was talking about the need to specify both files as mentioned on the
asf page [1] above:
bq. N.B. you must specify both the detached signature and the release file.
we don't seem to do it.
> Download page gpg example needs second parameter
>
>
> Key: OAK-8157
> URL: https://issues.apache.org/jira/browse/OAK-8157
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
>
> The download page [2] says:
> {quote}gpg --verify jackrabbit-X.Y.Z-src.zip.asc{quote}
> This should read:
> gpg --verify jackrabbit-X.Y.Z-src.zip.asc jackrabbit-X.Y.Z-src.zip
> It is important that the file being checked is also specified [1] on the
> command line.
> [1] [https://www.apache.org/info/verification.html#specify_both]
> [2] https://jackrabbit.apache.org/jcr/downloads.html#verify
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (OAK-8192) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu closed OAK-8192. - > Build failure: Unable to start docker container > --- > > Key: OAK-8192 > URL: https://issues.apache.org/jira/browse/OAK-8192 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2058 has failed. > First failed run: [Jackrabbit Oak > #2058|https://builds.apache.org/job/Jackrabbit%20Oak/2058/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2058/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8181) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8181. --- Resolution: Cannot Reproduce > Build failure: Unable to start docker container > --- > > Key: OAK-8181 > URL: https://issues.apache.org/jira/browse/OAK-8181 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2049 has failed. > First failed run: [Jackrabbit Oak > #2049|https://builds.apache.org/job/Jackrabbit%20Oak/2049/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2049/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8192) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8192: -- Summary: Build failure: Unable to start docker container (was: Build Jackrabbit Oak #2058 failed) > Build failure: Unable to start docker container > --- > > Key: OAK-8192 > URL: https://issues.apache.org/jira/browse/OAK-8192 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2058 has failed. > First failed run: [Jackrabbit Oak > #2058|https://builds.apache.org/job/Jackrabbit%20Oak/2058/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2058/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8192) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8192. --- Resolution: Cannot Reproduce > Build failure: Unable to start docker container > --- > > Key: OAK-8192 > URL: https://issues.apache.org/jira/browse/OAK-8192 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2058 has failed. > First failed run: [Jackrabbit Oak > #2058|https://builds.apache.org/job/Jackrabbit%20Oak/2058/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2058/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8181) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu updated OAK-8181: -- Summary: Build failure: Unable to start docker container (was: Build Jackrabbit Oak #2049 failed) > Build failure: Unable to start docker container > --- > > Key: OAK-8181 > URL: https://issues.apache.org/jira/browse/OAK-8181 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2049 has failed. > First failed run: [Jackrabbit Oak > #2049|https://builds.apache.org/job/Jackrabbit%20Oak/2049/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2049/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8181) Build failure: Unable to start docker container
[ https://issues.apache.org/jira/browse/OAK-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu closed OAK-8181. - > Build failure: Unable to start docker container > --- > > Key: OAK-8181 > URL: https://issues.apache.org/jira/browse/OAK-8181 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2049 has failed. > First failed run: [Jackrabbit Oak > #2049|https://builds.apache.org/job/Jackrabbit%20Oak/2049/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2049/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
