[jira] [Commented] (OAK-8393) Oak won't work on PGSQL, keeps reindexing and fails

2019-06-11 Thread Manuel Lara (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861744#comment-16861744
 ] 

Manuel Lara commented on OAK-8393:
--

I tried to make a non osgi version but had no luck, it gets too complicated as 
this class relies heavily on osgi features. As you said it is like the changes 
are not actually commited to the database (I am calling dispose), now it is 
failing now in reading the clusterId, but the real bug here is that changes are 
not reflected in database. Can you provide a non osgi functional implementation?

> Oak won't work on PGSQL, keeps reindexing and fails
> ---
>
> Key: OAK-8393
> URL: https://issues.apache.org/jira/browse/OAK-8393
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Manuel Lara
>Priority: Blocker
>
> Hi,
> I've been working with Oak using SegmentNodeStore without problems on 
> transient repos.
> Recently I have the requirement to set up a persistent repository on PGSQL. 
> This is the snippet:
>  
> {code:java}
> PlatformDBSM dbms = ctx.getBean(PlatformDBSM.class);
> RDBOptions options = new 
> RDBOptions().dropTablesOnClose(false).tablePrefix("oak_");
> DocumentNodeStore ns = 
> RDBDocumentNodeStoreBuilder.newRDBDocumentNodeStoreBuilder()
> .setRDBConnection(dbms.getDataSource(), options)
> .build();
> Repository repo = new Jcr(new Oak(ns)).createRepository();
> {code}
> When the tables are not present in the database Oak will create them 
> correctly and the repo works ok. However if I run this code for a second time 
> it will crash because it is always forcing a reindex for some reason, and it 
> either complaints about node types definitions not being consistent or 
> conflicts:
> {code:java}
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/rep:namedChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/jcr:childNodeDefinition
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/jcr:propertyDefinition
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 7:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 8:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:residualChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 8:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:namedChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:namedChildNodeDefinitions/jcr:system
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 2:/oak:index/counter was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 2:/oak:index/uuid was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 3:/oak:index/uuid/:index was already added in revision
> r16b2de3b67f-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1]

[jira] [Commented] (OAK-8393) Oak won't work on PGSQL, keeps reindexing and fails

2019-06-11 Thread Manuel Lara (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861348#comment-16861348
 ] 

Manuel Lara commented on OAK-8393:
--

I see what you mean. There should be a version of this class suitable for non 
osgi containers. I will most likely have to adapt this class so is can be used 
with spring in my case. I will post updates on that.

> Oak won't work on PGSQL, keeps reindexing and fails
> ---
>
> Key: OAK-8393
> URL: https://issues.apache.org/jira/browse/OAK-8393
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Manuel Lara
>Priority: Blocker
>
> Hi,
> I've been working with Oak using SegmentNodeStore without problems on 
> transient repos.
> Recently I have the requirement to set up a persistent repository on PGSQL. 
> This is the snippet:
>  
> {code:java}
> PlatformDBSM dbms = ctx.getBean(PlatformDBSM.class);
> RDBOptions options = new 
> RDBOptions().dropTablesOnClose(false).tablePrefix("oak_");
> DocumentNodeStore ns = 
> RDBDocumentNodeStoreBuilder.newRDBDocumentNodeStoreBuilder()
> .setRDBConnection(dbms.getDataSource(), options)
> .build();
> Repository repo = new Jcr(new Oak(ns)).createRepository();
> {code}
> When the tables are not present in the database Oak will create them 
> correctly and the repo works ok. However if I run this code for a second time 
> it will crash because it is always forcing a reindex for some reason, and it 
> either complaints about node types definitions not being consistent or 
> conflicts:
> {code:java}
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/rep:namedChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/jcr:childNodeDefinition
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/jcr:propertyDefinition
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 7:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 8:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:residualChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 8:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:namedChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:namedChildNodeDefinitions/jcr:system
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 2:/oak:index/counter was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 2:/oak:index/uuid was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 3:/oak:index/uuid/:index was already added in revision
> r16b2de3b67f-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1]
> at 
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:640)
> at 
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:366)

[jira] [Commented] (OAK-8351) Long running RGC remove and getmore operations

2019-06-11 Thread Stefan Egli (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861190#comment-16861190
 ] 

Stefan Egli commented on OAK-8351:
--

{quote}pending: test that covers MongoVersionGCSupport as there are currently 
no tests that do verify if deleteSplitDocuments does anything
{quote}
done in mentioned 
[branch|https://github.com/stefan-egli/jackrabbit-oak/tree/OAK-8351] now.

[~mreutegg], [~reschke], would you like to review the change? it's somewhat in 
a critical area...

> Long running RGC remove and getmore operations
> --
>
> Key: OAK-8351
> URL: https://issues.apache.org/jira/browse/OAK-8351
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk
>Affects Versions: 1.12.0
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>Priority: Major
>
> On a mongodb setup a long running revision garbage collection operation has 
> been witnessed. The query was running for hours. Doing a 
> {{planCacheSetFilter}}, which hinted mongodb to use a specific index, 
> together with killing the running command resolved the situation.
> The problem was that mongodb generated a query plan which scored high 
> (2.0003) but included an index scan through the {{\_id_}} index (and the 
> collection contained millions of documents). It also generated other, better, 
> plans, but they all "only" had the same high score, so it seemed legitimate 
> that mongodb would choose this one.
> The reason why this, problematic, query plan resulted in a high score seems 
> to be that it does indeed find 101 documents after entering the first "or" - 
> but during query execution it would also enter the other "or" parts where it 
> has chosen to do a {{\_id_}} index scan.
> The query involved was:
> {noformat}
>   {
>   "_sdType" : {
>   "$in" : [
>   
> 50,
>   
> 60,
>   
> 70
>   ]
>   },
>   "$or" : [
>   {
>   
> "_sdType" : 50
>   },
>   {
>   
> "_sdType" : 60
>   },
>   {
>   
> "_sdType" : 70,
>   
> "$or" : [
>   
> {
>   
> "_id" : /.*-1\/0/
>   
> },
>   
> {
>   
> "_id" : /[^-]*/,
>   
> "_path" : /.*-1\/0/
>   
> }
>   
> ],
>   
> "_sdMaxRevTime" : {
>   
> "$lt" : NumberLong(1551843365)
>   
> }
>   },
>   {
>   
> "_sdType" : 70,
>   
> "$or" : [
>   
> {
>   
> 

[jira] [Commented] (OAK-8339) Move jackrabbit-api project into Oak

2019-06-11 Thread Julian Reschke (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861083#comment-16861083
 ] 

Julian Reschke commented on OAK-8339:
-

I agree that we shouldn't do both at the same time.

The reason why I mentioned it was because it might be considered good if Oak 
didn't have any Jackrabbit dependencies anymore (the other one would be -data).

> Move jackrabbit-api project into Oak
> 
>
> Key: OAK-8339
> URL: https://issues.apache.org/jira/browse/OAK-8339
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.16.0
>
>
> {{jackrabbit-api}} contains extensions over the base JCR API. Although most 
> work happens in Oak, it still is a subproject of classic Jackrabbit. This 
> complicates evolution, because we need a stable release of Jackrabbit before 
> we can implement new/changed APIs in Oak.
> Going forward, we should however try to break this dependency. This will 
> eliminate the top reason why we have been branching Jackrabbit in the past.
> To do that, the following should work:
> - (svn) cp the subproject over to Oak (oak-jackrabbit-api), align the POM, 
> but do not touch
> package name or export versions
> - in Oak, use the new artefact instead of jackrabbit-api
> - once a new stable Oak is released (1.16, sometime later this year),
> drop the jackrabbit-api subproject in Jackrabit, and inside the other 
> Jackrabbit
> subprojects reference oak-jackrabbit-api instead
> - we probably should try to generate a "tombstone" release of
> jackrabbit-api, that would point people to the changed location (needs
> research...) before entirely removing the subproject



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-2644) Lift the 150 character limit on node names

2019-06-11 Thread Marcel Reutegger (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861076#comment-16861076
 ] 

Marcel Reutegger commented on OAK-2644:
---

bq. Are there any considerations to keep in mind when modifying these?

You should not modify those at all, unless you are experimenting on a dev 
system.

bq. Specifically to our use case, in rare instances we have nodes that goes 
beyond the default node name limit of 350 characters (500 characters is our 
max).

Would it be an option to store the long name in a property on that node and use 
the property value instead of the node name where appropriate?

> Lift the 150 character limit on node names
> --
>
> Key: OAK-2644
> URL: https://issues.apache.org/jira/browse/OAK-2644
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk, rdbmk
>Affects Versions: 1.0
>Reporter: Felix Meschberger
>Priority: Major
>
> Currently -- as of Oak 1.1.7 and 1.0.12 releases --  there is a limit on the 
> length of 150 characters for item names in Oak.
> This limit seems to be based upon a limitation in the MongoDB MK 
> implementation because MongoDB has a limit of 1024 bytes (I think) for 
> indexable properties.
> I think this limitation is highly unexpected and seems to be largeyl 
> undocumented. For previous users of Jackrabbit it should probably at least be 
> documented on the [Backwards 
> Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page.
> The main problem, though, I have with this limit is, that it is based on a 
> limitation of a particular MK implementation and hits through the full stack. 
> I would have rather expected such a persistence limitation to be fully hidden 
> and handled inside the MK implementation.
> Granted this limitation does not seem to violate the JCR 2.1 specification 
> which clearly states in section 3.2.4 Naming Restrictions:
> bq. This definition of JCR name represents the least restrictive set of 
> constraints permitted for the naming of items and other entities. A 
> repository may further restrict the names of entities to a subset of JCR 
> names and in most cases is encouraged to do so.
> and
> bq. A writable repository may enforce any implementation-specific constraint 
> by causing an exception to be thrown on an invalid JCR write method call. 
> Still I think it is a questionable limitation for a generic repository where 
> such names may be auto-generated and thus be quite long depending on the use 
> case.
> I understand this may be hard to fix but would still be happy to be able to 
> have (virtually) unlimited name length again as it was the case in Jackrabbit 
> 2.
> Thanks.
> See also OAK-333 for a previous discussion.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (OAK-2644) Lift the 150 character limit on node names

2019-06-11 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger reassigned OAK-2644:
-

Assignee: (was: Thomas Mueller)

> Lift the 150 character limit on node names
> --
>
> Key: OAK-2644
> URL: https://issues.apache.org/jira/browse/OAK-2644
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk, rdbmk
>Affects Versions: 1.0
>Reporter: Felix Meschberger
>Priority: Major
>
> Currently -- as of Oak 1.1.7 and 1.0.12 releases --  there is a limit on the 
> length of 150 characters for item names in Oak.
> This limit seems to be based upon a limitation in the MongoDB MK 
> implementation because MongoDB has a limit of 1024 bytes (I think) for 
> indexable properties.
> I think this limitation is highly unexpected and seems to be largeyl 
> undocumented. For previous users of Jackrabbit it should probably at least be 
> documented on the [Backwards 
> Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page.
> The main problem, though, I have with this limit is, that it is based on a 
> limitation of a particular MK implementation and hits through the full stack. 
> I would have rather expected such a persistence limitation to be fully hidden 
> and handled inside the MK implementation.
> Granted this limitation does not seem to violate the JCR 2.1 specification 
> which clearly states in section 3.2.4 Naming Restrictions:
> bq. This definition of JCR name represents the least restrictive set of 
> constraints permitted for the naming of items and other entities. A 
> repository may further restrict the names of entities to a subset of JCR 
> names and in most cases is encouraged to do so.
> and
> bq. A writable repository may enforce any implementation-specific constraint 
> by causing an exception to be thrown on an invalid JCR write method call. 
> Still I think it is a questionable limitation for a generic repository where 
> such names may be auto-generated and thus be quite long depending on the use 
> case.
> I understand this may be hard to fix but would still be happy to be able to 
> have (virtually) unlimited name length again as it was the case in Jackrabbit 
> 2.
> Thanks.
> See also OAK-333 for a previous discussion.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-8393) Oak won't work on PGSQL, keeps reindexing and fails

2019-06-11 Thread Marcel Reutegger (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861064#comment-16861064
 ] 

Marcel Reutegger commented on OAK-8393:
---

It most likely means the repository is not shut down properly and the first 
startup created the initial nodes, committed them, but they are not yet visible 
to the second repository instance.

Are you shutting down the node store with {{DocumentNodeStore.dispose()}}?

If you are using a DocumentNodeStore and not running in an OSGi container, then 
you also have to take care of some background jobs that need to be running. See 
the registration methods here: 
https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.14.0/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreService.java#L363-L365

More specifically, the LastRevRecoveryJob takes care of a crashed or 
non-gracefully shutdown DocumentNodeStore.

> Oak won't work on PGSQL, keeps reindexing and fails
> ---
>
> Key: OAK-8393
> URL: https://issues.apache.org/jira/browse/OAK-8393
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: Manuel Lara
>Priority: Blocker
>
> Hi,
> I've been working with Oak using SegmentNodeStore without problems on 
> transient repos.
> Recently I have the requirement to set up a persistent repository on PGSQL. 
> This is the snippet:
>  
> {code:java}
> PlatformDBSM dbms = ctx.getBean(PlatformDBSM.class);
> RDBOptions options = new 
> RDBOptions().dropTablesOnClose(false).tablePrefix("oak_");
> DocumentNodeStore ns = 
> RDBDocumentNodeStoreBuilder.newRDBDocumentNodeStoreBuilder()
> .setRDBConnection(dbms.getDataSource(), options)
> .build();
> Repository repo = new Jcr(new Oak(ns)).createRepository();
> {code}
> When the tables are not present in the database Oak will create them 
> correctly and the repo works ok. However if I run this code for a second time 
> it will crash because it is always forcing a reindex for some reason, and it 
> either complaints about node types definitions not being consistent or 
> conflicts:
> {code:java}
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/rep:namedChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/jcr:childNodeDefinition
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:NodeType/rep:namedChildNodeDefinitions/jcr:propertyDefinition
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 7:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 8:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:residualChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 8:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:namedChildNodeDefinitions
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 9:/oak:index/nodetype/:index/rep%3AChildNodeDefinitions/jcr:system/jcr:nodeTypes/rep:root/rep:namedChildNodeDefinitions/jcr:system
>  was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 2:/oak:index/counter was already added in revision
> r16b2de339a5-0-1 (older than base r16b2e6567db-0-1,r16b2e4bae94-0-2), before
> r16b2e65a3ef-0-1, 
> org.apache.jackrabbit.oak.plugins.document.ConflictException: The node 
> 

[jira] [Updated] (OAK-8396) Steps missing to run sweep on RDBDocumentStore

2019-06-11 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8396:

Component/s: rdbmk
 doc

> Steps missing to run sweep on RDBDocumentStore
> --
>
> Key: OAK-8396
> URL: https://issues.apache.org/jira/browse/OAK-8396
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc, rdbmk
>Reporter: Vinod Holani
>Priority: Minor
>
> Steps in [0] needs to be updated to run sweep on a RDBDocumentStore node.
> [0] : 
> https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#revision-gc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (OAK-8396) Steps missing to run sweep on RDBDocumentStore

2019-06-11 Thread Julian Reschke (JIRA)


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

Julian Reschke reassigned OAK-8396:
---

Assignee: Julian Reschke

> Steps missing to run sweep on RDBDocumentStore
> --
>
> Key: OAK-8396
> URL: https://issues.apache.org/jira/browse/OAK-8396
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc, rdbmk
>Reporter: Vinod Holani
>Assignee: Julian Reschke
>Priority: Minor
>
> Steps in [0] needs to be updated to run sweep on a RDBDocumentStore node.
> [0] : 
> https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#revision-gc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OAK-8396) Steps missing to run sweep on RDBDocumentStore

2019-06-11 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8396:

Fix Version/s: 1.16.0

> Steps missing to run sweep on RDBDocumentStore
> --
>
> Key: OAK-8396
> URL: https://issues.apache.org/jira/browse/OAK-8396
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc, rdbmk
>Reporter: Vinod Holani
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.16.0
>
>
> Steps in [0] needs to be updated to run sweep on a RDBDocumentStore node.
> [0] : 
> https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#revision-gc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (OAK-8396) Steps missing to run sweep on RDBDocumentStore

2019-06-11 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8396:

Issue Type: Technical task  (was: Documentation)
Parent: OAK-1266

> Steps missing to run sweep on RDBDocumentStore
> --
>
> Key: OAK-8396
> URL: https://issues.apache.org/jira/browse/OAK-8396
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Vinod Holani
>Priority: Minor
>
> Steps in [0] needs to be updated to run sweep on a RDBDocumentStore node.
> [0] : 
> https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#revision-gc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-8395) Build Jackrabbit Oak #2201 failed

2019-06-11 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861027#comment-16861027
 ] 

Hudson commented on OAK-8395:
-

Previously failing build now is OK.
 Passed run: [Jackrabbit Oak 
#2204|https://builds.apache.org/job/Jackrabbit%20Oak/2204/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/2204/console]

> Build Jackrabbit Oak #2201 failed
> -
>
> Key: OAK-8395
> URL: https://issues.apache.org/jira/browse/OAK-8395
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2201 has failed.
> First failed run: [Jackrabbit Oak 
> #2201|https://builds.apache.org/job/Jackrabbit%20Oak/2201/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2201/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-8339) Move jackrabbit-api project into Oak

2019-06-11 Thread Marcel Reutegger (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861033#comment-16861033
 ] 

Marcel Reutegger commented on OAK-8339:
---

Can you point to issues or changes when jackrabbit-jcr-commons had to be 
updated because Oak depended on it? I would limit this move to jackrabbit-api, 
unless there's a strong reason.

> Move jackrabbit-api project into Oak
> 
>
> Key: OAK-8339
> URL: https://issues.apache.org/jira/browse/OAK-8339
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.16.0
>
>
> {{jackrabbit-api}} contains extensions over the base JCR API. Although most 
> work happens in Oak, it still is a subproject of classic Jackrabbit. This 
> complicates evolution, because we need a stable release of Jackrabbit before 
> we can implement new/changed APIs in Oak.
> Going forward, we should however try to break this dependency. This will 
> eliminate the top reason why we have been branching Jackrabbit in the past.
> To do that, the following should work:
> - (svn) cp the subproject over to Oak (oak-jackrabbit-api), align the POM, 
> but do not touch
> package name or export versions
> - in Oak, use the new artefact instead of jackrabbit-api
> - once a new stable Oak is released (1.16, sometime later this year),
> drop the jackrabbit-api subproject in Jackrabit, and inside the other 
> Jackrabbit
> subprojects reference oak-jackrabbit-api instead
> - we probably should try to generate a "tombstone" release of
> jackrabbit-api, that would point people to the changed location (needs
> research...) before entirely removing the subproject



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-8328) Bug in index definition can block indexing / cause indexing in a loop

2019-06-11 Thread Nitin Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861030#comment-16861030
 ] 

Nitin Gupta commented on OAK-8328:
--

Update - There is a test case in oak-core failing with this patch . Will fix 
that and provide a new patch .

> Bug in index definition can block indexing / cause indexing in a loop
> -
>
> Key: OAK-8328
> URL: https://issues.apache.org/jira/browse/OAK-8328
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, lucene
>Reporter: Nitin Gupta
>Assignee: Thomas Mueller
>Priority: Major
> Attachments: OAK-8328.patch
>
>
> If we  set "/oak:index/indexName/entryCount" to a Long multi-valued property. 
> That will cause the system to reindex in a loop... You only see the root 
> cause if debug level logging is enabled. There are likely other such 
> problems. Oak should log a proper meaningful exception for config errors, and 
> if possible not get into this loop. It also blocks other indexes to be 
> updated I think.
>  
>  
> {code:java}
> 29.03.2019 11:58:55.688 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:00.691 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:05.685 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:10.687 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:15.685 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:20.688 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 12:13:50.692 *DEBUG* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index 
> update is still failing
> java.lang.IllegalStateException: null
>   at 
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.getValue(SegmentPropertyState.java:145)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:358)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:95)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition$Builder.build(IndexDefinition.java:314)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.enableReindexMode(LuceneIndexEditorContext.java:184)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.enter(LuceneIndexEditor.java:118)
>   at 
> org.apache.jackrabbit.oak.spi.commit.ProgressNotificationEditor.enter(ProgressNotificationEditor.java:71)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (OAK-8397) maven-bundle-plugin: add export instructions with baseline 1.14

2019-06-11 Thread angela (JIRA)
angela created OAK-8397:
---

 Summary: maven-bundle-plugin: add export instructions with 
baseline 1.14
 Key: OAK-8397
 URL: https://issues.apache.org/jira/browse/OAK-8397
 Project: Jackrabbit Oak
  Issue Type: Technical task
  Components: authorization-principalbased
Reporter: angela


interfaces in the _o.a.j.oak.spi.security.authorizatin.principalbased_ package 
are intended for customizations. baseline version should be 1.14



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (OAK-8391) Create AggregationFilter implementation

2019-06-11 Thread angela (JIRA)


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

angela reassigned OAK-8391:
---

Assignee: angela

> Create AggregationFilter implementation
> ---
>
> Key: OAK-8391
> URL: https://issues.apache.org/jira/browse/OAK-8391
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: angela
>Assignee: angela
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-8328) Bug in index definition can block indexing / cause indexing in a loop

2019-06-11 Thread Nitin Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860969#comment-16860969
 ] 

Nitin Gupta commented on OAK-8328:
--

Sure [~tmueller] - I will provide a test case too .

> Bug in index definition can block indexing / cause indexing in a loop
> -
>
> Key: OAK-8328
> URL: https://issues.apache.org/jira/browse/OAK-8328
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, lucene
>Reporter: Nitin Gupta
>Assignee: Thomas Mueller
>Priority: Major
> Attachments: OAK-8328.patch
>
>
> If we  set "/oak:index/indexName/entryCount" to a Long multi-valued property. 
> That will cause the system to reindex in a loop... You only see the root 
> cause if debug level logging is enabled. There are likely other such 
> problems. Oak should log a proper meaningful exception for config errors, and 
> if possible not get into this loop. It also blocks other indexes to be 
> updated I think.
>  
>  
> {code:java}
> 29.03.2019 11:58:55.688 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:00.691 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:05.685 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:10.687 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:15.685 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:20.688 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 12:13:50.692 *DEBUG* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index 
> update is still failing
> java.lang.IllegalStateException: null
>   at 
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.getValue(SegmentPropertyState.java:145)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:358)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:95)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition$Builder.build(IndexDefinition.java:314)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.enableReindexMode(LuceneIndexEditorContext.java:184)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.enter(LuceneIndexEditor.java:118)
>   at 
> org.apache.jackrabbit.oak.spi.commit.ProgressNotificationEditor.enter(ProgressNotificationEditor.java:71)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (OAK-8328) Bug in index definition can block indexing / cause indexing in a loop

2019-06-11 Thread Thomas Mueller (JIRA)


[ 
https://issues.apache.org/jira/browse/OAK-8328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16860956#comment-16860956
 ] 

Thomas Mueller commented on OAK-8328:
-

[~nitigup] It would still be good to have a test case.

> Bug in index definition can block indexing / cause indexing in a loop
> -
>
> Key: OAK-8328
> URL: https://issues.apache.org/jira/browse/OAK-8328
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, lucene
>Reporter: Nitin Gupta
>Assignee: Thomas Mueller
>Priority: Major
> Attachments: OAK-8328.patch
>
>
> If we  set "/oak:index/indexName/entryCount" to a Long multi-valued property. 
> That will cause the system to reindex in a loop... You only see the root 
> cause if debug level logging is enabled. There are likely other such 
> problems. Oak should log a proper meaningful exception for config errors, and 
> if possible not get into this loop. It also blocks other indexes to be 
> updated I think.
>  
>  
> {code:java}
> 29.03.2019 11:58:55.688 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:00.691 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:05.685 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:10.687 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:15.685 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 11:59:20.688 *INFO* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate Reindexing will be 
> performed for following indexes: [/oak:index/unifiedCreatedLucene]
> 29.03.2019 12:13:50.692 *DEBUG* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index 
> update is still failing
> java.lang.IllegalStateException: null
>   at 
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
>   at 
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.getValue(SegmentPropertyState.java:145)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:358)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:95)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition$Builder.build(IndexDefinition.java:314)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.enableReindexMode(LuceneIndexEditorContext.java:184)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.enter(LuceneIndexEditor.java:118)
>   at 
> org.apache.jackrabbit.oak.spi.commit.ProgressNotificationEditor.enter(ProgressNotificationEditor.java:71)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8232.
-

bulk close 1.14.0

> 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_8
> Fix For: 1.10.3, 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] [Closed] (OAK-8207) Read-only DocumentNodeStore tries to create root document

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8207.
-

bulk close 1.14.0

> Read-only DocumentNodeStore tries to create root document
> -
>
> Key: OAK-8207
> URL: https://issues.apache.org/jira/browse/OAK-8207
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
> Attachments: OAK-8207-1.8.diff
>
>
> When connecting a read-only DocumentNodeStore to a DocumentStore with an 
> empty {{nodes}} collection, the DocumentNodeStore tries to create the root 
> document. The operation then fails with something like:
> {noformat}
> Exception in thread "main" 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Method - 
> createOrUpdate. Params: [nodes, [key: 0:/ new 
> {_deleted.r16a020ebbbf-0-0=SET_MAP_ENTRY false, 
> _commitRoot.r16a020ebbbf-0-0=SET_MAP_ENTRY 0, _modified=MAX 1554812680}]]
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.asDocumentStoreException(DocumentStoreException.java:179)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:131)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException.convert(DocumentStoreException.java:114)
> at 
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:425)
> at 
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:280)
> at 
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:264)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.(DocumentNodeStore.java:624)
> at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBuilder.build(DocumentNodeStoreBuilder.java:174)
> at 
> org.apache.jackrabbit.oak.run.ClusterNodesCommand.execute(ClusterNodesCommand.java:65)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> Caused by: java.lang.UnsupportedOperationException: Method - createOrUpdate. 
> Params: [nodes, [key: 0:/ new {_deleted.r16a020ebbbf-0-0=SET_MAP_ENTRY false, 
> _commitRoot.r16a020ebbbf-0-0=SET_MAP_ENTRY 0, _modified=MAX 1554812680}]]
> at 
> org.apache.jackrabbit.oak.plugins.document.util.ReadOnlyDocumentStoreWrapperFactory$1.invoke(ReadOnlyDocumentStoreWrapperFactory.java:38)
> at com.sun.proxy.$Proxy0.createOrUpdate(Unknown Source)
> at 
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:365)
> ... 6 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8197) Update Oak 1.10 and trunk to Jackrabbit 2.18.1

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8197.
-

bulk close 1.14.0

> Update Oak 1.10 and trunk to Jackrabbit 2.18.1
> --
>
> Key: OAK-8197
> URL: https://issues.apache.org/jira/browse/OAK-8197
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10.3, 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8304) VersionablePathHook: Diff.setVersionablePath never results in CommitFailedException

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8304.
-

bulk close 1.14.0

> 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
> Fix For: 1.14.0
>
> 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] [Closed] (OAK-8334) Update Jackson dependency to 2.9.9

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8334.
-

bulk close 1.14.0

> Update Jackson dependency to 2.9.9
> --
>
> Key: OAK-8334
> URL: https://issues.apache.org/jira/browse/OAK-8334
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8324) Missing NotNull annotation with AuthenticationConfiguration and LoginModuleStatsCollector

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8324.
-

bulk close 1.14.0

> Missing NotNull annotation with AuthenticationConfiguration and 
> LoginModuleStatsCollector 
> --
>
> Key: OAK-8324
> URL: https://issues.apache.org/jira/browse/OAK-8324
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.14.0
>
>
> The interfaces {{AuthenticationConfiguration}} and 
> {{LoginModuleStatsCollector}} both lack NotNull annotation with a method. The 
> implementations either are not annotated either or are annotated with notnull 
> but don't perform any test for the parameter being null.
> [~stillalex], will fix accordingly both interfaces and implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8365) UserManagerImpl: unreacheable code when retrieving user/group from ID and tree

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8365.
-

bulk close 1.14.0

> UserManagerImpl: unreacheable code when retrieving user/group from ID and tree
> --
>
> Key: OAK-8365
> URL: https://issues.apache.org/jira/browse/OAK-8365
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> when retrieving user/group by id or tree the user mgr implementation will 
> verify that the id associated with a given tree actually is of type 
> authorizable and return null if that's not the case. consequently, line 437 
> in {{UserManagerImpl}} will never be reached.
> [~stillalex], i will refactor the code such that the ID lookup is limited to 
> one single place in {{getAuthorizable(Tree)}} and drop the extra if, which 
> will not be reached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8300) Revision GC may remove previous document without removing reference

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8300.
-

bulk close 1.14.0

> Revision GC may remove previous document without removing reference
> ---
>
> Key: OAK-8300
> URL: https://issues.apache.org/jira/browse/OAK-8300
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Affects Versions: 1.12.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> Depending on timing it may happen that the Revision GC removes a previous 
> document without updating the main document. This can only happen in a 
> cluster when modifications to a document happen on one cluster node and the 
> Revision GC runs on the other cluster node. Updating the main document on 
> Revision GC fails when the document was split after a background update that 
> contained the latest change on the document and the document is not updated 
> anymore. On the cluster node where the Revision GC runs, the document may 
> then stay in the cache in a state that doesn't reflect the split. When the 
> Revision GC runs, the main document from the cache will not show the 
> reference to the previous document.
> The Revision GC will print a log message that says like:
> {noformat}
> Split document 4:p/content/foo/r169f074b41f-0-1/0 for path 
> p/content/foo/r169f074b41f-0-1/0 not referenced anymore. Main document is 
> 2:/content/foo
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8256) PrincipalManagerImplTest uses Guava beta methods

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8256.
-

bulk close 1.14.0

> PrincipalManagerImplTest uses Guava beta methods
> 
>
> Key: OAK-8256
> URL: https://issues.apache.org/jira/browse/OAK-8256
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8290) Update org.apache.felix.framework for jdk13

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8290.
-

bulk close 1.14.0

> Update org.apache.felix.framework for jdk13
> ---
>
> Key: OAK-8290
> URL: https://issues.apache.org/jira/browse/OAK-8290
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: it
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_10, jdk13
> Fix For: 1.14.0
>
> Attachments: OAK-8290.diff
>
>
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.apache.felix.framework.URLHandlers 
> (file:/C:/Users/jre/.m2/repository/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar)
>  to constructor sun.net.www.protocol.file.Handler()
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.felix.framework.URLHandlers
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Creating bundle watcher 
> with scanner 
> [org.ops4j.pax.swissbox.extender.BundleManifestScanner@2834f898]...
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.apache.felix.framework]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.exam]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.exam.inject]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.exam.extender.service]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle [osgi.cmpn]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.base]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.swissbox.core]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.swissbox.extender]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.swissbox.framework]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.swissbox.lifecycle]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.swissbox.tracker]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.apache.geronimo.specs.geronimo-atinject_1.0_spec]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.tipi.junit]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.tipi.hamcrest.core]
> [org.ops4j.pax.swissbox.extender.BundleWatcher] : Scanning bundle 
> [org.ops4j.pax.exam.invoker.junit]
> ERROR: org.apache.felix.scr (15): Exception starting during restart
> java.lang.IllegalStateException: Stream handler unavailable.
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getDefaultPort(URLHandlersStreamHandlerProxy.java:180)
> at java.base/java.net.URL.getDefaultPort(URL.java:885)
> at java.base/sun.net.util.URLUtil.urlNoFragString(URLUtil.java:68)
> at java.base/java.security.CodeSource.(CodeSource.java:120)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:779)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:703)
> at 
> java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:584)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:633)
> at java.base/java.lang.Class.forName(Class.java:492)
> at 
> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:853)
> at 
> java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1077)
> at 
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)
> at 
> java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)
> at 
> java.base/sun.util.cldr.CLDRLocaleProviderAdapter$1.run(CLDRLocaleProviderAdapter.java:89)
> at 
> java.base/sun.util.cldr.CLDRLocaleProviderAdapter$1.run(CLDRLocaleProviderAdapter.java:86)
> at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:553)
> at 
> java.base/sun.util.cldr.CLDRLocaleProviderAdapter.(CLDRLocaleProviderAdapter.java:86)
> at 
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>  Method)
> at 
> 

[jira] [Closed] (OAK-8263) Simplify PermissionEntry.compareTo

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8263.
-

bulk close 1.14.0

> Simplify PermissionEntry.compareTo
> --
>
> Key: OAK-8263
> URL: https://issues.apache.org/jira/browse/OAK-8263
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: OAK-8263.patch
>
>
> [~stillalex], imho {{PermissionEntry.compareTo}} could be simplified by 
> calling {{Integer.compare}}. see attached patch. wdyt?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8318) Allow to close the SegmentStoreMigrator

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8318.
-

bulk close 1.14.0

> Allow to close the SegmentStoreMigrator
> ---
>
> Key: OAK-8318
> URL: https://issues.apache.org/jira/browse/OAK-8318
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-azure
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
>
> SegmentStoreMigrator creates a ExecutorService. We should be able to shut it 
> down, otherwise the hanging threads will block the standalone CLI tools from 
> closing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8247) Add non-admin mode for Node.isNodeType() benchmark

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8247.
-

bulk close 1.14.0

> 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] [Closed] (OAK-8340) Document use of oak-run for RDB

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8340.
-

bulk close 1.14.0

> Document use of oak-run for RDB
> ---
>
> Key: OAK-8340
> URL: https://issues.apache.org/jira/browse/OAK-8340
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.14.0
>
>
> Using oak-run with RDB is a bit tricky because oak-run does not contain
> - tomcat-jdbc (and its dependency tomcat-juli)
> - the actual JDBC driver
> Thus the JAR files need to be assembled, put into the classpath etc.
> Proposal:
> - include tomcat-jdbc and tomcat-juli into oak-run (see OAK-8341)
> - -supply a script for the remaining parts-



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8166) Index definition with orderable property definitions with and without functions breaks index

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8166.
-

bulk close 1.14.0

> Index definition with orderable property definitions with and without 
> functions breaks index
> 
>
> Key: OAK-8166
> URL: https://issues.apache.org/jira/browse/OAK-8166
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: indexing
>Affects Versions: 1.8.12
>Reporter: Tom Blackford
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-8166_1.patch, OAK-8166_2.patch
>
>
> If an index definition contains the same orderable property with and without 
> functions, it will fail to index any node which contains that property. The 
> failure will be logged as [1].
> Steps to reproduce:
> * Configure index with the two property definitions shown at [2].
> * Refresh the index definition
> * Modify a node that falls under the definition - it will fail with the 
> exception shown at [1]
> * Modify the 'non-function' index definition to not be orderable 
> (orderable=false)
> * Refresh the index definition
> * Modify the same node - note there is no exception.
> Thanks to [~catholicon] for assistance identifying root cause.
> [1]
> {code}
> 25.03.2019 15:39:04.135 *WARN* [async-index-update-async] 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor Failed to 
> index the node [/content/dam/Unknown-2.png]
> java.lang.IllegalArgumentException: DocValuesField 
> ":dvjcr:content/metadata/dc:title" appears more than once in this document 
> (only one value is allowed per field)
>   at 
> org.apache.lucene.index.SortedDocValuesWriter.addValue(SortedDocValuesWriter.java:62)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.DocValuesProcessor.addSortedField(DocValuesProcessor.java:125)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.DocValuesProcessor.addField(DocValuesProcessor.java:59)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.TwoStoredFieldsConsumers.addField(TwoStoredFieldsConsumers.java:36)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.DocFieldProcessor.processDocument(DocFieldProcessor.java:236)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:253)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:455)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1534) 
> [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1507) 
> [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.updateDocument(DefaultIndexWriter.java:86)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.addOrUpdate(LuceneIndexEditor.java:258)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:140)
>  [org.apache.jackrabbit.oak-lucene:1.8.9]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
>  [org.apache.jackrabbit.oak-store-spi:1.8.9]
> {code}
> [2] 
> {code}
> "dcTitle": {
> "jcr:primaryType": "nt:unstructured",
> "nodeScopeIndex": "true",
> "useInSuggest": "true",
> "ordered": "true",
> "propertyIndex": "true",
> "useInSpellcheck": "true",
> "name": "jcr:content/metadata/dc:title",
> "boost": "2.0"
> },
>   "dcTitleLowercase": {
> "jcr:primaryType": "nt:unstructured",
> "ordered": "true",
> "propertyIndex": "true",
> "function": "fn:lower-case(jcr:content/metadata/@dc:title)"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8286) Update jetbrains nullability annotations to 17.0.0

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8286.
-

bulk close 1.14.0

> Update jetbrains nullability annotations to 17.0.0
> --
>
> Key: OAK-8286
> URL: https://issues.apache.org/jira/browse/OAK-8286
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8350) Update animal-sniffer dependency to 1.18

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8350.
-

bulk close 1.14.0

> Update animal-sniffer dependency to 1.18
> 
>
> Key: OAK-8350
> URL: https://issues.apache.org/jira/browse/OAK-8350
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8257) RDBDocumentStore: improve trace logging of batch operations

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8257.
-

bulk close 1.14.0

> RDBDocumentStore: improve trace logging of batch operations
> ---
>
> Key: OAK-8257
> URL: https://issues.apache.org/jira/browse/OAK-8257
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10.3, 1.14.0
>
> Attachments: OAK-8257.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-7065) Remove orphan file from local directory in case indexing fails

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7065.
-

bulk close 1.14.0

> Remove orphan file from local directory in case indexing fails
> --
>
> Key: OAK-7065
> URL: https://issues.apache.org/jira/browse/OAK-7065
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7065.patch
>
>
> If an indexing cycle fails for some reason it may leave orphan files in local 
> directory. Later on in next indexing cycle Lucene would try to create files 
> with same name on local disk and this may fail on Windows where such files 
> may have been memory mapped and hence cannot  be deleted.
> We should analyze such a scenario and see if system can handle the failure 
> case properly



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8378) rdb/oak-run: update usage and documentation for garbage command

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8378.
-

bulk close 1.14.0

> rdb/oak-run: update usage and documentation for garbage command 
> 
>
> Key: OAK-8378
> URL: https://issues.apache.org/jira/browse/OAK-8378
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>
> ...which applies to jdbc:... as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8187) Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider and RestrictionProvider

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8187.
-

bulk close 1.14.0

> 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] [Closed] (OAK-8335) get rid of junit deprecation warnings

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8335.
-

bulk close 1.14.0

> get rid of junit deprecation warnings
> -
>
> Key: OAK-8335
> URL: https://issues.apache.org/jira/browse/OAK-8335
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: test
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10.3, 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8266) Redundant check for existing tree in CompiledPermissionImpl.buildVersionDelegatee

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8266.
-

bulk close 1.14.0

> Redundant check for existing tree in 
> CompiledPermissionImpl.buildVersionDelegatee
> -
>
> Key: OAK-8266
> URL: https://issues.apache.org/jira/browse/OAK-8266
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: OAK-8266.patch
>
>
> [~stillalex], i found that the check for existence of the passed tree in 
> {{CompiledPermissionImpl.buildVersionDelegatee}} is redundant, due to the 
> while loop just before calling the method. line 204ff:
> {code}
> while (!versionableTree.exists()) {
> versionableTree = versionableTree.getParent();
> }
> return new VersionTreePermission(tree, 
> buildVersionDelegatee(versionableTree), providerCtx.getTreeProvider());
> {code}
> and subsequently:
> {code}
> private TreePermission buildVersionDelegatee(@NotNull Tree versionableTree) {
> if (!versionableTree.exists()) {
> return TreePermission.EMPTY;
> } else if (versionableTree.isRoot()) {
> return createRootPermission(versionableTree);
> } 
> [...]
> }
> {code}
> due to the loop the method {{buildVersionDelegatee}} either gets an existing 
> tree or the root tree. IMO we should remove that extra if (see attached 
> patch). wdyt?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8215) Use CacheLIRS as default

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8215.
-

bulk close 1.14.0

> Use CacheLIRS as default
> 
>
> Key: OAK-8215
> URL: https://issues.apache.org/jira/browse/OAK-8215
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> Some benchmarks indicate performance is slightly better when using the Oak 
> CacheLIRS instead of the Guava Cache implementation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8241) Add benchmark for transient Node.setProperty()

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8241.
-

bulk close 1.14.0

> Add benchmark for transient Node.setProperty()
> --
>
> Key: OAK-8241
> URL: https://issues.apache.org/jira/browse/OAK-8241
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.10.3, 1.14.0
>
>
> Add a benchmark for a transient Node.setProperty(). There is already an 
> existing benchmark for setting and persisting a property. This issue is only 
> about the time it take to set the property without persisting the changes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8341) Include tomcat-jdbc/juli in oak-run

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8341.
-

bulk close 1.14.0

> Include tomcat-jdbc/juli in oak-run
> ---
>
> Key: OAK-8341
> URL: https://issues.apache.org/jira/browse/OAK-8341
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: rdbmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>
> This will increase oak-run by ~200K, but will make life much easier for 
> people needing oak-run for rdb instances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8368) RDBDocumentNodeStoreBuilder: refactor setRDBConnection for consistency

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8368.
-

bulk close 1.14.0

> RDBDocumentNodeStoreBuilder: refactor setRDBConnection for consistency
> --
>
> Key: OAK-8368
> URL: https://issues.apache.org/jira/browse/OAK-8368
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-7691) Remove deprecated ValueFactoryImpl methods

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7691.
-

bulk close 1.14.0

> Remove deprecated ValueFactoryImpl methods
> --
>
> Key: OAK-7691
> URL: https://issues.apache.org/jira/browse/OAK-7691
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: store-spi
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> The deprecated static methods on ValueFactoryImpl are not used anymore and 
> can be removed. See also OAK-7688.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8269) Improve readability of CompositePermissionProvider and CompositeTreePermission

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8269.
-

bulk close 1.14.0

> Improve readability of CompositePermissionProvider and CompositeTreePermission
> --
>
> Key: OAK-8269
> URL: https://issues.apache.org/jira/browse/OAK-8269
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: OAK-8269-2.patch, OAK-8269.patch
>
>
> [~stillalex], working on OAK-8155 i found myself struggling with the 
> complexity of {{CompositePermissionProvider}} and 
> {{CompositeTreePermissions}}. will see if i can come up with a patch that 
> would ease adding a proposal for OAK-8155.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8305) Don't log a warning for queries that use "option(traversal fail)"

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8305.
-

bulk close 1.14.0

> Don't log a warning for queries that use "option(traversal fail)"
> -
>
> Key: OAK-8305
> URL: https://issues.apache.org/jira/browse/OAK-8305
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently, a warning is logged for queries that use "option(traversal fail)" 
> in case the query is traversing (for example because there is no index, or an 
> index isn't ready yet).
> It would be better to log with debug level instead. That way, 
> "option(traversal fail)" can be used for flow control - try to run the query, 
> and if it fails, then the index isn't ready - for example for monitoring.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8231) Unreachable code in LoginModuleImpl.getLoginId

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8231.
-

bulk close 1.14.0

> 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
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> [~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] [Closed] (OAK-8295) Update version of jackrabbit dependency

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8295.
-

bulk close 1.14.0

> Update version of jackrabbit dependency
> ---
>
> Key: OAK-8295
> URL: https://issues.apache.org/jira/browse/OAK-8295
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: angela
>Priority: Major
> Fix For: 1.14.0
>
>
> in order to make the api extensions added with JCR-4429 available with a 
> stable version of _jackrabbit-api_, we should update the corresponding 
> version in the {{parent.pom}} once released.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8361) Improve tests for o.a.j.oak.security.user package

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8361.
-

bulk close 1.14.0

> Improve tests for o.a.j.oak.security.user package
> -
>
> Key: OAK-8361
> URL: https://issues.apache.org/jira/browse/OAK-8361
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.14.0
>
>
> same as OAK-8320 for o.a.j.oak.security.user



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8376) update commons-codec dependency to 1.12

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8376.
-

bulk close 1.14.0

> update commons-codec dependency to 1.12
> ---
>
> Key: OAK-8376
> URL: https://issues.apache.org/jira/browse/OAK-8376
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8278) RDBDataSourceFactory.CloseableDataSource doesn't implement java.sql.Wrapper correctly

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8278.
-

bulk close 1.14.0

> RDBDataSourceFactory.CloseableDataSource doesn't implement java.sql.Wrapper 
> correctly 
> --
>
> Key: OAK-8278
> URL: https://issues.apache.org/jira/browse/OAK-8278
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
>Priority: Trivial
> Fix For: 1.10.3, 1.14.0
>
>
> The class is supposed to wrap it's internal DataSource instance and should 
> implement the Wrapper interface accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8223) javadoc-plugin fails with java11

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8223.
-

bulk close 1.14.0

> javadoc-plugin fails with java11
> 
>
> Key: OAK-8223
> URL: https://issues.apache.org/jira/browse/OAK-8223
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Major
> Fix For: 1.14.0
>
>
> When generating javadoc with java11 it fails with 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar (default-cli) on 
> project oak-commons: Execution default-cli of goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar failed.: 
> NullPointerException -> [Help 1]
> {noformat}
> both {{javadoc:javadoc}} and {{javadoc:jar}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8265) Add nullable/notnull annotations to org.apache.jackrabbit.oak.security.authorization.permission.*

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8265.
-

bulk close 1.14.0

> Add nullable/notnull annotations to 
> org.apache.jackrabbit.oak.security.authorization.permission.*
> -
>
> Key: OAK-8265
> URL: https://issues.apache.org/jira/browse/OAK-8265
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.14.0
>
>
> [~stillalex], while working on tests i noticed that some classes in the 
> permission code base lack nullable/notnull annotations. if you don't object i 
> would go ahead adding them accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8370) Simplify o.a.j.oak.security.user.Utils.getOrAddTree

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8370.
-

bulk close 1.14.0

> Simplify o.a.j.oak.security.user.Utils.getOrAddTree
> ---
>
> Key: OAK-8370
> URL: https://issues.apache.org/jira/browse/OAK-8370
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> instead of accessing the tree first and re-iterating over all path segments 
> if it doesn't exist, the latter could be done right away and in addition use 
> {{TreeUtil.getOrAddChild}}, which also will take care of throw 
> {{AccessDeniedException}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8329) update docker-junit-rule dependency

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8329.
-

bulk close 1.14.0

> update docker-junit-rule dependency
> ---
>
> Key: OAK-8329
> URL: https://issues.apache.org/jira/browse/OAK-8329
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: continuous integration, test
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.14.0
>
>
> (just to rule out that the recently seen docker related Jenkins failures have 
> their cause here)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8358) oak-run check should have an option for specifying memory mapping

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8358.
-

bulk close 1.14.0

> oak-run check should have an option for specifying memory mapping
> -
>
> Key: OAK-8358
> URL: https://issues.apache.org/jira/browse/OAK-8358
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>  Labels: tooling
> Fix For: 1.14.0
>
>
> {{oak-run check}} currently uses memory mapping by default when building the 
> {{FileStore}}. This setting should be configurable, to allow switching memory 
> mapping off.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8349) RDBDocumentStore*: "reset clusterId tool" in oak-run

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8349.
-

bulk close 1.14.0

> RDBDocumentStore*: "reset clusterId tool" in oak-run
> 
>
> Key: OAK-8349
> URL: https://issues.apache.org/jira/browse/OAK-8349
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
> Attachments: OAK-8349-2.diff, OAK-8349.diff
>
>
> Make the run command added for OAK-4007 support RDB as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8320) Improve tests for o.a.j.oak.security.authentication.token package

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8320.
-

bulk close 1.14.0

> Improve tests for o.a.j.oak.security.authentication.token package
> -
>
> Key: OAK-8320
> URL: https://issues.apache.org/jira/browse/OAK-8320
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> - remove usage of deprecated {{NodeUtil}}
> - declare expected exceptions with test annotation
> - missing {{ContentSession.close}}
> - move duplicated utilities to {{AbstractTokenTest}}
> - redundant imports and exception declarations
> - improve coverage



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8217) Remove unused field DocumentNodeStoreBuilder#FAST_DIFF

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8217.
-

bulk close 1.14.0

> Remove unused field DocumentNodeStoreBuilder#FAST_DIFF
> --
>
> Key: OAK-8217
> URL: https://issues.apache.org/jira/browse/OAK-8217
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Trivial
> Fix For: 1.14.0
>
>
> This is a left over from refactoring. The field in use is now 
> {{DocumentNodeStore#FAST_DIFF}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8249.
-

bulk close 1.14.0

> 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.14.0
>
> 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] [Closed] (OAK-8281) Improve coverage for org.apache.jackrabbit.oak.security.authorization.composite

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8281.
-

bulk close 1.14.0

> Improve coverage for 
> org.apache.jackrabbit.oak.security.authorization.composite
> ---
>
> Key: OAK-8281
> URL: https://issues.apache.org/jira/browse/OAK-8281
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.14.0
>
>
> making this a subtask of OAK-8269



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8307) RDBDocumentStore: add DEBUG logging when fetching index metadata fails

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8307.
-

bulk close 1.14.0

> RDBDocumentStore: add DEBUG logging when fetching index metadata fails
> --
>
> Key: OAK-8307
> URL: https://issues.apache.org/jira/browse/OAK-8307
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8338) RDBDocumentStoreJDBC: fix theoretically possible NPE in perflogging code

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8338.
-

bulk close 1.14.0

> RDBDocumentStoreJDBC: fix theoretically possible NPE in perflogging code
> 
>
> Key: OAK-8338
> URL: https://issues.apache.org/jira/browse/OAK-8338
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Trivial
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8331) Update Tika dependency to 1.21

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8331.
-

bulk close 1.14.0

> Update Tika dependency to 1.21
> --
>
> Key: OAK-8331
> URL: https://issues.apache.org/jira/browse/OAK-8331
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8379) Improve tests for o.a.j.oak.security.authorization

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8379.
-

bulk close 1.14.0

> Improve tests for o.a.j.oak.security.authorization
> --
>
> Key: OAK-8379
> URL: https://issues.apache.org/jira/browse/OAK-8379
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> similar to OAK-8320 for {{o.a.j.oak.security.authorization}}. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8276) OR-CompositeTreePermission.grantsPermission should loop over aggregates of supported permissions

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8276.
-

bulk close 1.14.0

> OR-CompositeTreePermission.grantsPermission should loop over aggregates of 
> supported permissions
> 
>
> Key: OAK-8276
> URL: https://issues.apache.org/jira/browse/OAK-8276
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> [~stillalex], issue as discussed in person: while working on OAK-8269 and the 
> missing tests for the ORing {{CompositeTreePermission}} i noticed the 
> following issue in {{grantsPermission}}: after obtaining the supported 
> permissions the code loops over the individual permissions aggregated. but 
> passes the original permission instead of the supported ones which 
> potentially only include a subset.
> the affected code inside the method looks as follows:
> {code}
> long supported = providers[i].supportedPermissions(tp, property, 
> permissions);
> if (doEvaluate(supported)) {
> if (compositionType == AND) {
>[...]
> } else {
> for (long p : Permissions.aggregates(permissions)) {
> // < issue line 221 
> [...]
> }
> }
> }
> {code}
> IMO the code at line 221 should rather be as follows:
> {code}
> for (long p : Permissions.aggregates(supported)) {
> {code}
> i will go ahead fix it along with a test case that illustrates the issue. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8337) RDBDocumentStore: refactor index dumping code

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8337.
-

bulk close 1.14.0

> RDBDocumentStore: refactor index dumping code 
> --
>
> Key: OAK-8337
> URL: https://issues.apache.org/jira/browse/OAK-8337
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
> Attachments: OAK-8337.diff
>
>
> ...to reduce casting and improve readability.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8317) Move the version-related migration tools to the oak-core

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8317.
-

bulk close 1.14.0

> Move the version-related migration tools to the oak-core
> 
>
> Key: OAK-8317
> URL: https://issues.apache.org/jira/browse/OAK-8317
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: upgrade
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
>
> The oak-upgrade module contains a package with the VersionableEditor and 
> related classes. RepositorySidegrade uses them to migrate a version histories 
> from one repository to another. We should move it to the oak-core, so they 
> can be reused by other modules that deals with the migration (eg. the 
> InitialContentMigrator in the oak-store-composite).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8277) Run tests on travis-ci.org on MongoDB 4.0.x

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8277.
-

bulk close 1.14.0

> Run tests on travis-ci.org on MongoDB 4.0.x
> ---
>
> Key: OAK-8277
> URL: https://issues.apache.org/jira/browse/OAK-8277
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.10.3, 1.14.0
>
>
> Tests currently use MongoDB 3.6.4 and should be updated to the most recent 
> stable version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8149) java 12 javadoc fails with "unknown tag" for OSGi version annotations in package-info

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8149.
-

bulk close 1.14.0

> java 12 javadoc fails with "unknown tag" for OSGi version annotations in 
> package-info
> -
>
> Key: OAK-8149
> URL: https://issues.apache.org/jira/browse/OAK-8149
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>
> {noformat}
> [ERROR] 
> C:\projects\apache\oak\trunk\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\package-info.java:17:
>  error: unknown tag: Version
> [ERROR] @Version("1.3.0")
> [ERROR] ^
> [ERROR] 
> C:\projects\apache\oak\trunk\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\cache\package-info.java:17:
>  error: unknown tag: Version
> [ERROR] @Version("1.0.0")
> [ERROR] ^
> [ERROR] 
> C:\projects\apache\oak\trunk\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\concurrent\package-info.java:17:
>  error: unknown tag: Version
> [ERROR] @Version("1.0.1")
> [ERROR] ^
> [ERROR] 
> C:\projects\apache\oak\trunk\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\io\package-info.java:17:
>  error: unknown tag: Version
> [ERROR] @Version("1.0.0")
> [ERROR] ^
> [ERROR] 
> C:\projects\apache\oak\trunk\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\json\package-info.java:17:
>  error: unknown tag: Version
> [ERROR] @Version("1.0.1")
> [ERROR] ^
> [ERROR] 
> C:\projects\apache\oak\trunk\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\sort\package-info.java:17:
>  error: unknown tag: Version
> [ERROR] @Version("1.0.1")
> [ERROR] ^
> [ERROR]
> {noformat}
> (fails for me on Windows but also in the Windows Linux subsystem)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8360) UserAuthentication.authenticate: improve readability

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8360.
-

bulk close 1.14.0

> UserAuthentication.authenticate: improve readability
> 
>
> Key: OAK-8360
> URL: https://issues.apache.org/jira/browse/OAK-8360
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8209) Improve Node.isNodeType(String) performance

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8209.
-

bulk close 1.14.0

> 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
> Fix For: 1.14.0
>
> 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] [Closed] (OAK-8312) MissingLastRevSeeker and NodeDocumentSweeper: improve progress logging

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8312.
-

bulk close 1.14.0

> MissingLastRevSeeker and NodeDocumentSweeper: improve progress logging
> --
>
> Key: OAK-8312
> URL: https://issues.apache.org/jira/browse/OAK-8312
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
>
> We currently log progress every 10 nodes, which can take a lot of time on 
> slow systems.
> Proposal:
>  - log based on a time interval, not number of nodes
>  - each time, log cluster node id being recovered as well
>  - log rate (nodes/per time unit)
>  - -not only log number of suspects but also nodes that need recovery-



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8373) UserPrincipalProvider: redundant test for null in ResultRowToPrincipal, EveryonePredicate

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8373.
-

bulk close 1.14.0

> UserPrincipalProvider: redundant test for null in ResultRowToPrincipal, 
> EveryonePredicate
> -
>
> Key: OAK-8373
> URL: https://issues.apache.org/jira/browse/OAK-8373
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{ResultRowToPrincipal}} function and {{EveryonePredicate}} check for 
> principal parameter in {{apply}} to be null but the passed principals will 
> never be null.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8229) LoginModuleImpl.commit will end in NPE if credentials are null

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8229.
-

bulk close 1.14.0

> LoginModuleImpl.commit will end in NPE if credentials are null
> --
>
> Key: OAK-8229
> URL: https://issues.apache.org/jira/browse/OAK-8229
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.14.0
>
>
> [~stillalex], i spotted an NPE with {{LoginModuleImpl.commit}} under the 
> following circumstances:
> - no {{Credentials}} have been extracted during the login() (see 
> {{getCredentials}}
> - if the {{Subject}} is not read-only commit() will add the null credentials 
> objects to the public credentials set
> - the subsequent attempt to also add the {{AuthInfo}} will result in a NPE.
> the fix should be fairly easy, avoiding pushing null credentials to the 
> subject
> {code}
> if (!subject.isReadOnly()) {
> Set principals = subject.getPrincipals();
> if (principal != null) {
> principals.addAll(getPrincipals(principal));
> } else if (userId != null) {
> principals.addAll(getPrincipals(userId));
> }
> // FIX: extra check for null
> if (credentials != null) {
> subject.getPublicCredentials().add(credentials);
> }
> setAuthInfo(createAuthInfo(principals), subject);
> } else {
> log.debug("Could not add information to read only subject 
> {}", subject);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8323) Refactor redundant checks for null in TokenValidator

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8323.
-

bulk close 1.14.0

> Refactor redundant checks for null in TokenValidator
> 
>
> Key: OAK-8323
> URL: https://issues.apache.org/jira/browse/OAK-8323
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: OAK-8323.patch
>
>
> [~stillalex], due to missing nullability annotations in 
> {{org.apache.jackrabbit.oak.spi.commit,Validator}} interface, some old 
> implementations in the security code base like {{TokenValidator}} perform 
> redundant checks for null that would only occur in case of invalid sequences 
> of {{Validator.childNodeAdded}} followed by {{Validator.childNodeChanged}} 
> (or similar examples with delete/add and delete/change). I would prefer to 
> verify the expected non-null state and have the subsequent not perform extra 
> checks for null that are never executed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8208) oak-run/rdb: add --rdbtableprefix option

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8208.
-

bulk close 1.14.0

> oak-run/rdb: add --rdbtableprefix option
> 
>
> Key: OAK-8208
> URL: https://issues.apache.org/jira/browse/OAK-8208
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: rdbmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10.3, 1.14.0
>
> Attachments: OAK-8208.diff
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8363) Remove obsolete comment

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8363.
-

bulk close 1.14.0

> Remove obsolete comment
> ---
>
> Key: OAK-8363
> URL: https://issues.apache.org/jira/browse/OAK-8363
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Trivial
> Fix For: 1.10.3, 1.14.0
>
>
> There's an obsolete comment, which is a left over from OAK-7316.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8228) Optimize PathUtils.dropIndexFromName(String)

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8228.
-

bulk close 1.14.0

> Optimize PathUtils.dropIndexFromName(String)
> 
>
> Key: OAK-8228
> URL: https://issues.apache.org/jira/browse/OAK-8228
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: commons
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> The implementation of {{PathUtils.dropIndexFromName(String)}} can easily be 
> optimized for the regular case when the name does not have an index suffix. 
> The current pattern matching taking place every time is rather expensive.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8270) Add variant of PermissionUtil.getReadOnlyTree that never returns null

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8270.
-

bulk close 1.14.0

> Add variant of PermissionUtil.getReadOnlyTree that never returns null
> -
>
> Key: OAK-8270
> URL: https://issues.apache.org/jira/browse/OAK-8270
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-8270.patch
>
>
> the current implementation of {{PermissionUtil.getReadOnlyTree}} may have a 
> null tree passed and will in this case return {{null}}, which is not suited 
> for those parts of the permission evaluation where the {{Tree}} cannot be 
> null and a non-null return-value is therefore expected.
> [~stillalex], i would therefore suggest to rename the existing method to 
> {{getReadOnlyTreeOrNull}} and add a variant that never returns null. see 
> attached patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8322) Create documentation for Oakathons

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8322.
-

bulk close 1.14.0

> Create documentation for Oakathons
> --
>
> Key: OAK-8322
> URL: https://issues.apache.org/jira/browse/OAK-8322
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Minor
> Fix For: 1.14.0
>
>
> Document Oakathons - what they are, the purpose they fulfill, general 
> guidelines for planning and cadence, etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8199) DocumentStore in ReadOnly mode should never modify persistence

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8199.
-

bulk close 1.14.0

> DocumentStore in ReadOnly mode should never modify persistence
> --
>
> Key: OAK-8199
> URL: https://issues.apache.org/jira/browse/OAK-8199
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk, rdbmk
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
>
> Currently, the readonly mode is implemented using a wrapper around the 
> DocumentStore, rejecting read operations. That is not sufficient, due to:
> - potential DB initialization (indices)
> - calls that bypass the DocumentStore API (like for GC operations)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8216) Consistently add nullability annotations with spi.nodetype package and implementation

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8216.
-

bulk close 1.14.0

> Consistently add nullability annotations with spi.nodetype package and 
> implementation
> -
>
> Key: OAK-8216
> URL: https://issues.apache.org/jira/browse/OAK-8216
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, core-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> while investigating the NPE found with OAK-8212, i noticed that the 
> interfaces in org.apache.jackrabbit.oak.spi.nodetype don't have consistent 
> NotNull/Nullable annotations.
> it should be straight forward to add those and adjust the implementation in 
> oak-core accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8357) Support the truncate operation for the GCJournalFile

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8357.
-

bulk close 1.14.0

> Support the truncate operation for the GCJournalFile
> 
>
> Key: OAK-8357
> URL: https://issues.apache.org/jira/browse/OAK-8357
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-azure, segment-tar
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
>
> The new {{truncate}} method, similar to the one in the JournalFile, would 
> remove the content of the gc.log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8362) UserImporter: redundant check for null principals

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8362.
-

bulk close 1.14.0

> UserImporter: redundant check for null principals
> -
>
> Key: OAK-8362
> URL: https://issues.apache.org/jira/browse/OAK-8362
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{UserImporter.handlePropInfo}} contains an extra check for the 'principals' 
> field being null, which is never the case. the extra if can be removed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8355) AuthorizableImpl.isEveryone should not throw RepositoryException

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8355.
-

bulk close 1.14.0

> AuthorizableImpl.isEveryone should not throw RepositoryException
> 
>
> Key: OAK-8355
> URL: https://issues.apache.org/jira/browse/OAK-8355
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: 1.14
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{AuthorizableImpl.isEveryone}} should be refactored such that it doesn't 
> throw {{RepositoryException}}, which doesn't add any value for this internal 
> method.
> [~stillalex], fyi



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8346) RDBDocumentStore*: fix several potential but improbable NPEs

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8346.
-

bulk close 1.14.0

> RDBDocumentStore*: fix several potential but improbable NPEs
> 
>
> Key: OAK-8346
> URL: https://issues.apache.org/jira/browse/OAK-8346
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8369) Misplace checkNotNull in CacheValidator

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8369.
-

bulk close 1.14.0

> Misplace checkNotNull in CacheValidator
> ---
>
> Key: OAK-8369
> URL: https://issues.apache.org/jira/browse/OAK-8369
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{CacheValidator}} has checks for {{parentAfter}} being null 
> {{childNodeAdded}}, which is never true, instead of asserting that 
> {{parentBefore}} is not null in {{childNodeChanged}}, which according to the 
> validator contract should always be the case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8261) Indexing lane failing but the index is not marked corrupt

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8261.
-

bulk close 1.14.0

> Indexing lane failing but the index is not marked corrupt
> -
>
> Key: OAK-8261
> URL: https://issues.apache.org/jira/browse/OAK-8261
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: indexing
>Reporter: Mohit Kataria
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: 
> 0001-OAK-8261-Indexing-lane-failing-but-the-index-is-not-.patch, 
> 0002-OAK-8261-Formatting-changes-Indexing-lane-failing-bu.patch, 
> 0003-OAK-8261-Indexing-lane-failing-but-the-index-is-not-.patch, trace.log
>
>
> Steps to reproduce issue:
> Delete blob filesystem(in case of tarmk) from repository/datastore and empty 
> repository/index folder.
> Now asyncIndexUpdate will run periodically and fail but index won't get 
> marked as corrupt. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8372) DeclaredMembershipPredicate contains redundant lookup of groupTree

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8372.
-

bulk close 1.14.0

> DeclaredMembershipPredicate contains redundant lookup of groupTree
> --
>
> Key: OAK-8372
> URL: https://issues.apache.org/jira/browse/OAK-8372
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> line 52 in {{DeclaredMembershipPredicate}} retrieves the _groupTree_ again 
> instead of using the value of the lookup obtained earlier. While fixing this 
> i additionally noticed that the contentIds obtained on the same line could be 
> filtered for non-null values. this improvement would allow to consequently 
> drop the extra check for null in the {{apply}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8185) Improve CompositeNodeStore fixture

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8185.
-

bulk close 1.14.0

> Improve CompositeNodeStore fixture
> --
>
> Key: OAK-8185
> URL: https://issues.apache.org/jira/browse/OAK-8185
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Marcel Reutegger
>Assignee: Tomek Rękawek
>Priority: Minor
> Fix For: 1.10.3, 1.14.0
>
> Attachments: OAK-8185-update-fixture.patch, composite-node-builder.txt
>
>
> While working on OAK-8141 I noticed the benchmark numbers for GetDeepNodeTest 
> on Oak-Composite-Store are rather low compared to Oak-Segment-Tar.
> {noformat}
> Apache Jackrabbit Oak 1.12-SNAPSHOT
> # GetDeepNodeTest  C min 10% 50% 90% max  
>  N 
> Oak-Segment-Tar1  35  37  39  41  64  
>   1524
> Oak-Composite-Store1 203 204 208 214 236  
>288
> {noformat}
> In an offline conversation [~tomek.rekawek] mentioned the overhead shouldn't 
> be that big because the implementation should switch to the non-composite 
> implementation as soon as the read operation traverses into the 
> global/writable node store. It seems however, this is not the case  when 
> running GetDeepNodeTest. So, this may well be a bug and not an improvement, 
> as filed at the moment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8284) Improvements to EntryPredicate

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8284.
-

bulk close 1.14.0

> Improvements to EntryPredicate
> --
>
> Key: OAK-8284
> URL: https://issues.apache.org/jira/browse/OAK-8284
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: EntryPredicate.patch
>
>
> [~stillalex], while working on overall coverage of the permission evaluation 
> code base i found  
> {{org.apache.jackrabbit.oak.security.authorization.permission.EntryPredicate}}
>  confusing and hard to understand. attached patch contains an attempt to 
> simplify and improve this class central to permission evaluation by 
> completely separating the 3 major cases: 
> - evaluation for repository level (no path, no tree), 
> - evaluation based on a non-null path and finally 
> - evaluation based on a non-null tree object and an optional property. 
> feedback welcome.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8375) DocumentNodeStoreBuilder should not instantiate BlobStore instance before "build()"

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8375.
-

bulk close 1.14.0

> DocumentNodeStoreBuilder should not instantiate BlobStore instance before 
> "build()"
> ---
>
> Key: OAK-8375
> URL: https://issues.apache.org/jira/browse/OAK-8375
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8311) RDBDocumentStore: allow to turn off RDB-specific MissingLastRevSeeker

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8311.
-

bulk close 1.14.0

> RDBDocumentStore: allow to turn off RDB-specific MissingLastRevSeeker
> -
>
> Key: OAK-8311
> URL: https://issues.apache.org/jira/browse/OAK-8311
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.10.3, 1.14.0, 1.8.14
>
> Attachments: OAK-8311.diff
>
>
> Make the type of RDB MissingLastRevSeeker configurable based on a system 
> property, defaulting to "enabled" for Oak trunk.
> - makes it easier to compare performance in a single version
> - makes it possible to backport the code change without actually enabling it 
> by default



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8310) Potentially misleading conflict exception message

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8310.
-

bulk close 1.14.0

> Potentially misleading conflict exception message
> -
>
> Key: OAK-8310
> URL: https://issues.apache.org/jira/browse/OAK-8310
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Affects Versions: 1.8.0, 1.10.0, 1.12.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: candidate_oak_1_10, candidate_oak_1_8
> Fix For: 1.14.0
>
>
> A conflicting merge on a DocumentNodeStore may have a misleading exception 
> message, when a node is added that already exists and the existing node has 
> changes that were done after it was added.
> The conflict message will then say there's an existing node that was added at 
> the revision it was last modified instead of when it was added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8306) Empty PrincipalProvider cache breaks membership collection

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8306.
-

bulk close 1.14.0

> 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] [Closed] (OAK-8354) Fix/Add nullability annotations with o.a.j.oak.security.user package

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8354.
-

bulk close 1.14.0

> Fix/Add nullability annotations with o.a.j.oak.security.user package
> 
>
> Key: OAK-8354
> URL: https://issues.apache.org/jira/browse/OAK-8354
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (OAK-8356) Support append mode in the SegmentStoreMigrator

2019-06-11 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8356.
-

bulk close 1.14.0

> Support append mode in the SegmentStoreMigrator
> ---
>
> Key: OAK-8356
> URL: https://issues.apache.org/jira/browse/OAK-8356
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-azure
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
>
> In case the target segment store already exists, it should be possible to 
> only append the missing segments from the source and update the metadata, 
> skipping the existing archives.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


  1   2   >