[jira] [Updated] (OAK-8245) Add column for executed statement to "explain" Query row, next to 'plan' column.

2019-04-15 Thread Mark Adamcin (JIRA)


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

Mark Adamcin updated OAK-8245:
--
Description: 
The "explain" behavior of the core Query is very useful for helping to debug 
JCR query execution planning. For xpath queries, the resulting "plan" column 
refers to the result of running XPathToSQL2Converter to produce a JCR-SQL2 
statement for execution. This SQL2 statement should be exposed through the same 
API as the "plan", by way of an additional column named "statement" in the 
single result row. 

At this time, this underlying SQL2 statement is inaccessible to users of the 
JCR Query interface, which can only provide the original XPath statement.

To access the converted SQL2 statement, a class targeting the JCR API must 
implement a regular expression match against a log stream retrieved via slf4j 
MDC.

This facility is not very portable, and an effective pattern on one version of 
Oak may not be effective on a different version of Oak, for any number of 
reasons.

Also, the XPathToSQL2Converter package is not exported in an OSGi environment, 
so client code cannot use that API to reconstruct the SQL2 statement in 
parallel.

  was:
The "explain" behavior of the core Query is very useful for helping to debug 
JCR query execution planning. For xpath queries, the resulting "plan" column 
refers to the result of running XPathToSQL2Converter to produce a JCR-SQL2 
statement for execution. This SQL2 statement should be exposed through the same 
API as the "plan", by way of an additional column named "statement" in the 
single result row. 

At this time, this underlying SQL2 statement is inaccessible to users of the 
JCR Query interface, which can only provide the original XPath statement.

To access the converted SQL2 statement, a class targeting the JCR API must 
implement a regular expression match against a log stream retrieved via slf4j 
MDC.

This facility is not very portable, and an effective pattern on one version of 
Oak may not be effective on a different version of Oak, for any number of 
reasons.

Also, the XPathToSQL2Converter package is not exported in an OSGi environment, 
so client code cannot use that API to reconstruct the SQL2 statement in 
parralel.


> Add column for executed statement to "explain" Query row, next to 'plan' 
> column.
> 
>
> Key: OAK-8245
> URL: https://issues.apache.org/jira/browse/OAK-8245
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Affects Versions: 1.12.0
>Reporter: Mark Adamcin
>Priority: Minor
>
> The "explain" behavior of the core Query is very useful for helping to debug 
> JCR query execution planning. For xpath queries, the resulting "plan" column 
> refers to the result of running XPathToSQL2Converter to produce a JCR-SQL2 
> statement for execution. This SQL2 statement should be exposed through the 
> same API as the "plan", by way of an additional column named "statement" in 
> the single result row. 
> At this time, this underlying SQL2 statement is inaccessible to users of the 
> JCR Query interface, which can only provide the original XPath statement.
> To access the converted SQL2 statement, a class targeting the JCR API must 
> implement a regular expression match against a log stream retrieved via slf4j 
> MDC.
> This facility is not very portable, and an effective pattern on one version 
> of Oak may not be effective on a different version of Oak, for any number of 
> reasons.
> Also, the XPathToSQL2Converter package is not exported in an OSGi 
> environment, so client code cannot use that API to reconstruct the SQL2 
> statement in parallel.



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


[jira] [Updated] (OAK-8245) Add column for executed statement to "explain" Query row, next to 'plan' column.

2019-04-15 Thread Mark Adamcin (JIRA)


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

Mark Adamcin updated OAK-8245:
--
Flags: Patch

Patch via GitHub PR#125

> Add column for executed statement to "explain" Query row, next to 'plan' 
> column.
> 
>
> Key: OAK-8245
> URL: https://issues.apache.org/jira/browse/OAK-8245
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Affects Versions: 1.12.0
>Reporter: Mark Adamcin
>Priority: Minor
>
> The "explain" behavior of the core Query is very useful for helping to debug 
> JCR query execution planning. For xpath queries, the resulting "plan" column 
> refers to the result of running XPathToSQL2Converter to produce a JCR-SQL2 
> statement for execution. This SQL2 statement should be exposed through the 
> same API as the "plan", by way of an additional column named "statement" in 
> the single result row. 
> At this time, this underlying SQL2 statement is inaccessible to users of the 
> JCR Query interface, which can only provide the original XPath statement.
> To access the converted SQL2 statement, a class targeting the JCR API must 
> implement a regular expression match against a log stream retrieved via slf4j 
> MDC.
> This facility is not very portable, and an effective pattern on one version 
> of Oak may not be effective on a different version of Oak, for any number of 
> reasons.
> Also, the XPathToSQL2Converter package is not exported in an OSGi 
> environment, so client code cannot use that API to reconstruct the SQL2 
> statement in parralel.



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


[jira] [Created] (OAK-8245) Add column for executed statement to "explain" Query row, next to 'plan' column.

2019-04-15 Thread Mark Adamcin (JIRA)
Mark Adamcin created OAK-8245:
-

 Summary: Add column for executed statement to "explain" Query row, 
next to 'plan' column.
 Key: OAK-8245
 URL: https://issues.apache.org/jira/browse/OAK-8245
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: query
Affects Versions: 1.12.0
Reporter: Mark Adamcin


The "explain" behavior of the core Query is very useful for helping to debug 
JCR query execution planning. For xpath queries, the resulting "plan" column 
refers to the result of running XPathToSQL2Converter to produce a JCR-SQL2 
statement for execution. This SQL2 statement should be exposed through the same 
API as the "plan", by way of an additional column named "statement" in the 
single result row. 

At this time, this underlying SQL2 statement is inaccessible to users of the 
JCR Query interface, which can only provide the original XPath statement.

To access the converted SQL2 statement, a class targeting the JCR API must 
implement a regular expression match against a log stream retrieved via slf4j 
MDC.

This facility is not very portable, and an effective pattern on one version of 
Oak may not be effective on a different version of Oak, for any number of 
reasons.

Also, the XPathToSQL2Converter package is not exported in an OSGi environment, 
so client code cannot use that API to reconstruct the SQL2 statement in 
parralel.



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


[jira] [Commented] (OAK-8244) Build Jackrabbit Oak #2091 failed

2019-04-15 Thread Hudson (JIRA)


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

Hudson commented on OAK-8244:
-

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

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



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


[jira] [Created] (OAK-8244) Build Jackrabbit Oak #2091 failed

2019-04-15 Thread Hudson (JIRA)
Hudson created OAK-8244:
---

 Summary: Build Jackrabbit Oak #2091 failed
 Key: OAK-8244
 URL: https://issues.apache.org/jira/browse/OAK-8244
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: continuous integration
Reporter: Hudson


No description is provided

The build Jackrabbit Oak #2091 has failed.
First failed run: [Jackrabbit Oak 
#2091|https://builds.apache.org/job/Jackrabbit%20Oak/2091/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/2091/console]



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


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

2019-04-15 Thread Manfred Baedke (JIRA)


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

Manfred Baedke edited comment on OAK-8232 at 4/15/19 3:27 PM:
--

Removed the existence check and commited 
[http://svn.apache.org/viewvc?view=revision=1857589]

Removed unused import: 
http://svn.apache.org/viewvc?view=revision=1857592


was (Author: baedke):
Removed the existence check and commited 
http://svn.apache.org/viewvc?view=revision=1857589

> Node#setPrimaryType(String) does not create child nodes defined as autoCreated
> --
>
> Key: OAK-8232
> URL: https://issues.apache.org/jira/browse/OAK-8232
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.12.0
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
>Priority: Minor
>  Labels: candidate_oak_1_12
> Fix For: 1.14.0
>
> Attachments: oak-8232-testcase.patch, oak-8232.patch
>
>
> In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does 
> not create child nodes that are defined as autoCreated. See attached failing 
> test case.



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


[jira] [Comment Edited] (OAK-8173) Add branch coverage to Jacoco check

2019-04-15 Thread angela (JIRA)


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

angela edited comment on OAK-8173 at 4/15/19 3:06 PM:
--

[~reschke], unfortunately not i ran the build on java 8 and 11 but don't 
have a windows machine at hand. i will adjust the numbers such that the build 
passes for you as well. imo the important piece that we may not to change/add a 
lot of code in the security area without adding/caring about testing. i don't 
care about the exact numbers.

-> done at revision 1857591 (hope that solves the issue for you)



was (Author: anchela):
[~reschke], unfortunately not i ran the build on java 8 and 11 but don't 
have a windows machine at hand. i will adjust the numbers such that the build 
passes for you as well. imo the important piece that we may not to change/add a 
lot of code in the security area without adding caring about testing. i don't 
care about the exact numbers.

-> done at revision 1857591 (hope that solves the issue for you)


> Add branch coverage to Jacoco check
> ---
>
> Key: OAK-8173
> URL: https://issues.apache.org/jira/browse/OAK-8173
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: auth-external, auth-ldap, authorization-cug, commons, 
> core, parent, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-8173.patch
>
>
> i would suggest to add branch coverage extending the existing check for line 
> coverage. note: while the jacoco plugin is defined the parent pom the check 
> is currently disabled by default and thus only affects modules which have it 
> explicitly enabled (i.e. security related modules as well as _oak-core_ and 
> _oak-commons_).



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


[jira] [Comment Edited] (OAK-8173) Add branch coverage to Jacoco check

2019-04-15 Thread angela (JIRA)


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

angela edited comment on OAK-8173 at 4/15/19 3:05 PM:
--

[~reschke], unfortunately not i ran the build on java 8 and 11 but don't 
have a windows machine at hand. i will adjust the numbers such that the build 
passes for you as well. imo the important piece that we may not to change/add a 
lot of code in the security area without adding caring about testing. i don't 
care about the exact numbers.

-> done at revision 1857591 (hope that solves the issue for you)



was (Author: anchela):
[~reschke], unfortunately not i ran the build on java 8 and 11 but don't 
have a windows machine at hand. i will adjust the numbers such that the build 
passes for you as well. imo the important piece that we may not to change/add a 
lot of code in the security area without adding caring about testing. i don't 
care about the exact numbers.

> Add branch coverage to Jacoco check
> ---
>
> Key: OAK-8173
> URL: https://issues.apache.org/jira/browse/OAK-8173
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: auth-external, auth-ldap, authorization-cug, commons, 
> core, parent, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-8173.patch
>
>
> i would suggest to add branch coverage extending the existing check for line 
> coverage. note: while the jacoco plugin is defined the parent pom the check 
> is currently disabled by default and thus only affects modules which have it 
> explicitly enabled (i.e. security related modules as well as _oak-core_ and 
> _oak-commons_).



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


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

2019-04-15 Thread Manfred Baedke (JIRA)


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

Manfred Baedke updated OAK-8232:

Fix Version/s: 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
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: oak-8232-testcase.patch, oak-8232.patch
>
>
> In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does 
> not create child nodes that are defined as autoCreated. See attached failing 
> test case.



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


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

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8232:

Labels: candidate_oak_1_12  (was: )

> Node#setPrimaryType(String) does not create child nodes defined as autoCreated
> --
>
> Key: OAK-8232
> URL: https://issues.apache.org/jira/browse/OAK-8232
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.12.0
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
>Priority: Minor
>  Labels: candidate_oak_1_12
> Fix For: 1.14.0
>
> Attachments: oak-8232-testcase.patch, oak-8232.patch
>
>
> In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does 
> not create child nodes that are defined as autoCreated. See attached failing 
> test case.



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


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

2019-04-15 Thread Manfred Baedke (JIRA)


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

Manfred Baedke resolved OAK-8232.
-
Resolution: Fixed
  Assignee: Manfred Baedke

> 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
> Fix For: 1.14.0
>
> Attachments: oak-8232-testcase.patch, oak-8232.patch
>
>
> In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does 
> not create child nodes that are defined as autoCreated. See attached failing 
> test case.



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


[jira] [Commented] (OAK-8173) Add branch coverage to Jacoco check

2019-04-15 Thread angela (JIRA)


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

angela commented on OAK-8173:
-

[~reschke], unfortunately not i ran the build on java 8 and 11 but don't 
have a windows machine at hand. i will adjust the numbers such that the build 
passes for you as well. imo the important piece that we may not to change/add a 
lot of code in the security area without adding caring about testing. i don't 
care about the exact numbers.

> Add branch coverage to Jacoco check
> ---
>
> Key: OAK-8173
> URL: https://issues.apache.org/jira/browse/OAK-8173
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: auth-external, auth-ldap, authorization-cug, commons, 
> core, parent, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-8173.patch
>
>
> i would suggest to add branch coverage extending the existing check for line 
> coverage. note: while the jacoco plugin is defined the parent pom the check 
> is currently disabled by default and thus only affects modules which have it 
> explicitly enabled (i.e. security related modules as well as _oak-core_ and 
> _oak-commons_).



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


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

2019-04-15 Thread Manfred Baedke (JIRA)


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

Manfred Baedke commented on OAK-8232:
-

Removed the existence check and commited 
http://svn.apache.org/viewvc?view=revision=1857589

> Node#setPrimaryType(String) does not create child nodes defined as autoCreated
> --
>
> Key: OAK-8232
> URL: https://issues.apache.org/jira/browse/OAK-8232
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.12.0
>Reporter: Manfred Baedke
>Priority: Minor
> Attachments: oak-8232-testcase.patch, oak-8232.patch
>
>
> In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does 
> not create child nodes that are defined as autoCreated. See attached failing 
> test case.



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


[jira] [Commented] (OAK-8173) Add branch coverage to Jacoco check

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8173:
-

This check is currently failing on one of my two (Windows) machines with:

{noformat}
[WARNING] Rule violated for bundle oak-auth-external: lines covered ratio is 
0.83, but expected minimum is 0.84
[WARNING] Rule violated for bundle oak-auth-external: branches covered ratio is 
0.81, but expected minimum is 0.82
{noformat}

Both machines execute the same number of tests (490, 1 skipped).

[~anchela]: any idea how to debug this?

> Add branch coverage to Jacoco check
> ---
>
> Key: OAK-8173
> URL: https://issues.apache.org/jira/browse/OAK-8173
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: auth-external, auth-ldap, authorization-cug, commons, 
> core, parent, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-8173.patch
>
>
> i would suggest to add branch coverage extending the existing check for line 
> coverage. note: while the jacoco plugin is defined the parent pom the check 
> is currently disabled by default and thus only affects modules which have it 
> explicitly enabled (i.e. security related modules as well as _oak-core_ and 
> _oak-commons_).



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


[jira] [Created] (OAK-8243) Expose the number of SNFEs as metric

2019-04-15 Thread Andrei Dulceanu (JIRA)
Andrei Dulceanu created OAK-8243:


 Summary: Expose the number of SNFEs as metric
 Key: OAK-8243
 URL: https://issues.apache.org/jira/browse/OAK-8243
 Project: Jackrabbit Oak
  Issue Type: New Feature
  Components: segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
 Fix For: 1.14.0


I want to expose the number of {{SegmentNotFoundException}}s as metric.



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


[jira] [Created] (OAK-8242) JavaDoc error in oak-authorization-principalbased

2019-04-15 Thread Marcel Reutegger (JIRA)
Marcel Reutegger created OAK-8242:
-

 Summary: JavaDoc error in oak-authorization-principalbased
 Key: OAK-8242
 URL: https://issues.apache.org/jira/browse/OAK-8242
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: security
Reporter: Marcel Reutegger


Building JavaDoc in oak-authorization-principalbased with {{mvn 
javadoc:javadoc}} fails with:
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:javadoc (default-cli) on 
project oak-authorization-principalbased: An error has occurred in Javadoc 
report generation: 
[ERROR] Exit code: 1 - 
/Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/FilterProvider.java:35:
 error: @param name not found
[ERROR]  * @param absPath The absolute oak path to be tested.
[ERROR]   ^
[ERROR] 
/Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/FilterProvider.java:38:
 warning: no @param for oakPath
[ERROR] boolean handlesPath(@NotNull String oakPath);
[ERROR] ^
[ERROR] 
/Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/principalbased/impl/FilterProviderImpl.java:47:
 error: reference not found
[ERROR]  * Implementation of the {@link 
org.apache.jackrabbit.spi.security.authorization.principalbased.Filter} 
interface that
[ERROR] ^
[ERROR] 
[ERROR] Command line was: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/../bin/javadoc
 @options @packages
[ERROR] 
[ERROR] Refer to the generated Javadoc files in 
'/Users/marcel/devel/apache/oak_clean/trunk/oak-authorization-principalbased/target/site/apidocs'
 dir.
{noformat}



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


[jira] [Closed] (OAK-8236) Build Jackrabbit Oak #2086 failed

2019-04-15 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger closed OAK-8236.
-

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



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


[jira] [Resolved] (OAK-8236) Build Jackrabbit Oak #2086 failed

2019-04-15 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger resolved OAK-8236.
---
Resolution: Duplicate

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



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


[jira] [Assigned] (OAK-8213) BlobStore instantiated from ReadOnly DocumentNodeStore should never modify persistence

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke reassigned OAK-8213:
---

Assignee: Julian Reschke

> BlobStore instantiated from ReadOnly DocumentNodeStore should never modify 
> persistence
> --
>
> Key: OAK-8213
> URL: https://issues.apache.org/jira/browse/OAK-8213
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: blob, documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>
> Currently the "readOnly" setting is only passed to the underlying 
> DocumentStore, but not a BlobStore.



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


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

2019-04-15 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger updated OAK-8241:
--
Fix Version/s: 1.10.3

Merged into 1.10 branch to have a more stable baseline: 
http://svn.apache.org/r1857578

> 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] [Resolved] (OAK-8241) Add benchmark for transient Node.setProperty()

2019-04-15 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger resolved OAK-8241.
---
   Resolution: Fixed
Fix Version/s: 1.14.0

Done in trunk: http://svn.apache.org/r1857577

> 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.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] [Created] (OAK-8241) Add benchmark for transient Node.setProperty()

2019-04-15 Thread Marcel Reutegger (JIRA)
Marcel Reutegger created OAK-8241:
-

 Summary: 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


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] [Commented] (OAK-8232) Node#setPrimaryType(String) does not create child nodes defined as autoCreated

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8232:
-

+1 to both (removing the check, and refactoring later) - testing without the 
check right now.

> Node#setPrimaryType(String) does not create child nodes defined as autoCreated
> --
>
> Key: OAK-8232
> URL: https://issues.apache.org/jira/browse/OAK-8232
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.12.0
>Reporter: Manfred Baedke
>Priority: Minor
> Attachments: oak-8232-testcase.patch, oak-8232.patch
>
>
> In contrast to Node#addNode(String, String), Node#setPrimaryType(String) does 
> not create child nodes that are defined as autoCreated. See attached failing 
> test case.



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


[jira] [Commented] (OAK-8236) Build Jackrabbit Oak #2086 failed

2019-04-15 Thread Hudson (JIRA)


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

Hudson commented on OAK-8236:
-

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

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



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


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

2019-04-15 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger resolved OAK-8228.
---
Resolution: Fixed

Applied changes from GitHub branch to trunk: http://svn.apache.org/r1857569

> 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] [Commented] (OAK-8239) Fail in getting started

2019-04-15 Thread Karim Hamdi (JIRA)


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

Karim Hamdi commented on OAK-8239:
--

Thanks for the answer, I send a mail to the dev mailing list. 

Cheers

> Fail in getting started 
> 
>
> Key: OAK-8239
> URL: https://issues.apache.org/jira/browse/OAK-8239
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: api
>Affects Versions: 1.10.2
>Reporter: Karim Hamdi
>Priority: Major
>  Labels: newbie
> Attachments: Screen Shot 2019-04-12 at 5.46.53 PM.png, Screen Shot 
> 2019-04-12 at 5.55.33 PM.png
>
>
> Hi the Oak team,
>  
> We are looking to use Appache Oak as Content Management System in our project.
> Looking at what Oak is capable of make us really interested and we want to 
> try it.
> The problem is that the Getting Started page is not up to date for the 1.10.2 
> version (Last Stable release) we think.
>  
> For example in the repository Construction. We want to use a MongoDB Backend, 
> the problem is that the methode _getDB_ is *deprecated*
> DocumentMK is not available anymore in the plugings of Oak core. I found a 
> [Jira 
> ticket|https://jira.apache.org/jira/browse/OAK-7023?jql=text%20~%20%22DocumentMK%22]
>  that says it is now Deprecated and that we should use 
> MongoDocumentNodeStoreBuilderbut without any more notice.  
> I tried  this:
> {color:#707070}_DocumentNodeStore ns1 = 
> MongoDocumentNodeStoreBuilder.newMongoDocumentNodeStoreBuilder().setMongoDB("mongodb://localhost:27017",
>  "test1234", 0).build();_{color}
> But I get the exception in the attach files.
>  
> Is there any Up to Date or even some others tutorial we can use to get 
> started with Oak ?
>  
> With the Best regards,
>  
> Karim Hamdi



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


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

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8199:

Fix Version/s: 1.8.13

> 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] [Comment Edited] (OAK-8146) oak-run support for inspecting clusterNodeInfo

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke edited comment on OAK-8146 at 4/15/19 11:49 AM:
---

trunk: [r1857247|http://svn.apache.org/r1857247]
1.10: [r1857300|http://svn.apache.org/r1857300]
1.8: [r1857568|http://svn.apache.org/r1857568]



was (Author: reschke):
trunk: [r1857247|http://svn.apache.org/r1857247]
1.10: [r1857300|http://svn.apache.org/r1857300]


> oak-run support for inspecting clusterNodeInfo
> --
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_6
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
> Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146-3.diff, 
> OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries (later)



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


[jira] [Updated] (OAK-8146) oak-run support for inspecting clusterNodeInfo

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8146:

Fix Version/s: 1.8.13

> oak-run support for inspecting clusterNodeInfo
> --
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_8
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
> Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146-3.diff, 
> OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries (later)



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


[jira] [Updated] (OAK-8146) oak-run support for inspecting clusterNodeInfo

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8146:

Labels: candidate_oak_1_6  (was: candidate_oak_1_8)

> oak-run support for inspecting clusterNodeInfo
> --
>
> Key: OAK-8146
> URL: https://issues.apache.org/jira/browse/OAK-8146
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: documentmk, run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_6
> Fix For: 1.8.13, 1.10.3, 1.14.0
>
> Attachments: OAK-8146-1.patch, OAK-8146-2.diff, OAK-8146-3.diff, 
> OAK-8146.diff, OAK-8146.diff
>
>
> - readable dump of cluster node info entries
> - command to purge selected entries (later)



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


[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions

2019-04-15 Thread angela (JIRA)


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

angela commented on OAK-8234:
-

[~stillalex], one additional observation: if the distinction between 
administrative and non-administrative principal set is taken care of in 
{{AuthorizationConfigurationImpl}} shouldn't we remove that check then in 
{{PermissionProviderImpl}}? Also: isn't {{AllPermissions}} then redundant and 
should be removed?

> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin 
> sessions, but we can still do better by simply not creating many of the 
> objects needed as parameters for the {{CompiledPermissions}} which will be 
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via 
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used 
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!



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


[jira] [Assigned] (OAK-8240) Improve test coverage for org.apache.jackrabbit.oak.security.authorization.permission

2019-04-15 Thread angela (JIRA)


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

angela reassigned OAK-8240:
---

Assignee: angela

> Improve test coverage for 
> org.apache.jackrabbit.oak.security.authorization.permission
> -
>
> Key: OAK-8240
> URL: https://issues.apache.org/jira/browse/OAK-8240
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Critical
>
> as mentioned in OAK-8234, we should improve test-coverage for the permission 
> evaluation code base before making improvements and or refactoring.



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


[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions

2019-04-15 Thread angela (JIRA)


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

angela commented on OAK-8234:
-

[~stillalex], the patch for {{AuthorizationConfigurationImpl}} looks good to 
me. i still think it's wrong to ignore the test case that fails. in fact the 
test class that contains the failing test is called 
{{PermissionProviderImplTest}} but apparently it doesn't test 
{{PermissionProviderImpl}} but the {{AllPermissionProviderImpl}}. So quite 
obviously it doesn't test the class it claims to test adjusting the 
{{createPermissionProviderImpl}} method should do the trick... maybe creating 
{{PermissionProviderImpl}} instance manually instead of letting the 
configuration create it?
Also: I would like the new class {{AllPermissionProviderImpl}} to come with a 
dedicated test class with unit tests. Also an extra test for 
{{AuthorizationConfigurationImpl}}...

> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin 
> sessions, but we can still do better by simply not creating many of the 
> objects needed as parameters for the {{CompiledPermissions}} which will be 
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via 
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used 
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!



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


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

2019-04-15 Thread angela (JIRA)


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

angela resolved OAK-8231.
-
   Resolution: Fixed
Fix Version/s: 1.14.0

Committed revision 1857565.


> 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] [Resolved] (OAK-8239) Fail in getting started

2019-04-15 Thread Marcel Reutegger (JIRA)


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

Marcel Reutegger resolved OAK-8239.
---
Resolution: Not A Problem

Please use the mailing list to ask questions. See: 
http://jackrabbit.apache.org/jcr/mailing-lists.html

The exception you see, indicates that you are most likely using a MongoDB Java 
Driver that doesn't match the version expected by Oak 1.10.x. The driver 
version should be 3.8.x.

> Fail in getting started 
> 
>
> Key: OAK-8239
> URL: https://issues.apache.org/jira/browse/OAK-8239
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: api
>Affects Versions: 1.10.2
>Reporter: Karim Hamdi
>Priority: Major
>  Labels: newbie
> Attachments: Screen Shot 2019-04-12 at 5.46.53 PM.png, Screen Shot 
> 2019-04-12 at 5.55.33 PM.png
>
>
> Hi the Oak team,
>  
> We are looking to use Appache Oak as Content Management System in our project.
> Looking at what Oak is capable of make us really interested and we want to 
> try it.
> The problem is that the Getting Started page is not up to date for the 1.10.2 
> version (Last Stable release) we think.
>  
> For example in the repository Construction. We want to use a MongoDB Backend, 
> the problem is that the methode _getDB_ is *deprecated*
> DocumentMK is not available anymore in the plugings of Oak core. I found a 
> [Jira 
> ticket|https://jira.apache.org/jira/browse/OAK-7023?jql=text%20~%20%22DocumentMK%22]
>  that says it is now Deprecated and that we should use 
> MongoDocumentNodeStoreBuilderbut without any more notice.  
> I tried  this:
> {color:#707070}_DocumentNodeStore ns1 = 
> MongoDocumentNodeStoreBuilder.newMongoDocumentNodeStoreBuilder().setMongoDB("mongodb://localhost:27017",
>  "test1234", 0).build();_{color}
> But I get the exception in the attach files.
>  
> Is there any Up to Date or even some others tutorial we can use to get 
> started with Oak ?
>  
> With the Best regards,
>  
> Karim Hamdi



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


[jira] [Comment Edited] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions

2019-04-15 Thread Alex Deparvu (JIRA)


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

Alex Deparvu edited comment on OAK-8234 at 4/15/19 10:05 AM:
-

bq. Alex Deparvu, while the intended change makes a lot of sense to me, i don't 
particularly like the delegatee approach with yet another redirection. in 
particular since it creates a lot of changes to the PermissionProviderImpl that 
might result in subtle regressions. Is there a reason for not making the 
distinction between administrative subjects and regular subjects right in the 
AuthorizationConfigurationImpl? that would place that fundamental difference 
between set of principals that are subjected to permission evaluation vs those 
that are not prominently in the flow. also for administrative principals the 
whole Mount handling is IMO redundant and which is not taken into account in 
the patch as far as i saw. wdyt?

Interesting suggestion, I had not considered this but it makes more sense to 
inject the admin provider directly in the {{AuthorizationConfigurationImpl}}. 
I'll update the patch.

[edit] updated the patch and rebased the branch so it reads cleaner




was (Author: alex.parvulescu):
bq. Alex Deparvu, while the intended change makes a lot of sense to me, i don't 
particularly like the delegatee approach with yet another redirection. in 
particular since it creates a lot of changes to the PermissionProviderImpl that 
might result in subtle regressions. Is there a reason for not making the 
distinction between administrative subjects and regular subjects right in the 
AuthorizationConfigurationImpl? that would place that fundamental difference 
between set of principals that are subjected to permission evaluation vs those 
that are not prominently in the flow. also for administrative principals the 
whole Mount handling is IMO redundant and which is not taken into account in 
the patch as far as i saw. wdyt?

Interesting suggestion, I had not considered this but it makes more sense to 
inject the admin provider directly in the {{AuthorizationConfigurationImpl}}. 
I'll update the patch.





> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin 
> sessions, but we can still do better by simply not creating many of the 
> objects needed as parameters for the {{CompiledPermissions}} which will be 
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via 
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used 
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!



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


[jira] [Commented] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on OAK-8200:
-

trunk: (1.12.0) [r1857104|http://svn.apache.org/r1857104]
1.10: [r1857284|http://svn.apache.org/r1857284]
1.8: [r1857555|http://svn.apache.org/r1857555]


> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12.0, 1.8.13, 1.10.3
>
> Attachments: OAK-8200-1.8.patch
>
>




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


[jira] [Commented] (OAK-8234) Reduce object allocation in PermissionProviderImpl for admin sessions

2019-04-15 Thread Alex Deparvu (JIRA)


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

Alex Deparvu commented on OAK-8234:
---

bq. Alex Deparvu, while the intended change makes a lot of sense to me, i don't 
particularly like the delegatee approach with yet another redirection. in 
particular since it creates a lot of changes to the PermissionProviderImpl that 
might result in subtle regressions. Is there a reason for not making the 
distinction between administrative subjects and regular subjects right in the 
AuthorizationConfigurationImpl? that would place that fundamental difference 
between set of principals that are subjected to permission evaluation vs those 
that are not prominently in the flow. also for administrative principals the 
whole Mount handling is IMO redundant and which is not taken into account in 
the patch as far as i saw. wdyt?

Interesting suggestion, I had not considered this but it makes more sense to 
inject the admin provider directly in the {{AuthorizationConfigurationImpl}}. 
I'll update the patch.





> Reduce object allocation in PermissionProviderImpl for admin sessions
> -
>
> Key: OAK-8234
> URL: https://issues.apache.org/jira/browse/OAK-8234
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>
> There was already a lot of work done here to improve efficiency of admin 
> sessions, but we can still do better by simply not creating many of the 
> objects needed as parameters for the {{CompiledPermissions}} which will be 
> ignored anyway in the case of admin sessions.
> Ex: There are a lot of immutable trees (created via 
> {{PermissionUtil.getReadOnlyTree(tree, immutableRoot)}}) that are not used 
> for the evaluation.
> Thanks to [~mreutegg] for spotting this one!



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


[jira] [Issue Comment Deleted] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8200:

Comment: was deleted

(was: trunk: (1.12.0) [r1857104|http://svn.apache.org/r1857104]
1.10: [r1857284|http://svn.apache.org/r1857284]
)

> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12.0, 1.8.13, 1.10.3
>
> Attachments: OAK-8200-1.8.patch
>
>




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


[jira] [Updated] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8200:

Fix Version/s: 1.8.13

> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.12.0, 1.8.13, 1.10.3
>
> Attachments: OAK-8200-1.8.patch
>
>




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


[jira] [Updated] (OAK-8200) MongoDocumentStore in ReadOnly mode should never modify persistence

2019-04-15 Thread Julian Reschke (JIRA)


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

Julian Reschke updated OAK-8200:

Labels: candidate_oak_1_6  (was: candidate_oak_1_8)

> MongoDocumentStore in ReadOnly mode should never modify persistence
> ---
>
> Key: OAK-8200
> URL: https://issues.apache.org/jira/browse/OAK-8200
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: mongomk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12.0, 1.8.13, 1.10.3
>
> Attachments: OAK-8200-1.8.patch
>
>




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


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

2019-04-15 Thread angela (JIRA)


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

angela reassigned OAK-8231:
---

Assignee: angela

> 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
>
> [~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-8140) UserPrincipalProvider support for full text search

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8140.
-

bulk close 1.12.0

> UserPrincipalProvider support for full text search
> --
>
> Key: OAK-8140
> URL: https://issues.apache.org/jira/browse/OAK-8140
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: principal-management-extensions
> Fix For: 1.12.0
>
>
> The {{UserPrincipalProvider}} related changes for OAK-8131.



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


[jira] [Closed] (OAK-8021) PrivilegeBitsProvider.getBits(Privilege[],NameMapper) should use getOakNameOrNull

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8021.
-

bulk close 1.12.0

> PrivilegeBitsProvider.getBits(Privilege[],NameMapper) should use 
> getOakNameOrNull 
> --
>
> Key: OAK-8021
> URL: https://issues.apache.org/jira/browse/OAK-8021
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
>
> just noticed that the implementation of 
> {{PrivilegeBitsProvider.getBits(Privilege[], NameMapper)}} could call 
> {{NameMapper.getOakNameOrNull}} instead of {{getOakName}}, which throws a 
> {{RepositoryException}} in case of an invalid name.
> [~stillalex], fyi



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


[jira] [Closed] (OAK-8119) Let similarity search rerank use distance as exact score

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8119.
-

bulk close 1.12.0

> Let similarity search rerank use distance as exact score
> 
>
> Key: OAK-8119
> URL: https://issues.apache.org/jira/browse/OAK-8119
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0, 1.10.2
>
>
> Currently the reranking algorithm for feature vector similarity search uses 
> an additive scoring mechanism so that the final score is the sum of the 
> original LSH query and the query - document feature vector distance. It turns 
> out that since LSH is supposed to approximate the fv distance it'd be more 
> effective to just use the exact distance as the final score instead of 
> performing the mentioned sum.



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


[jira] [Closed] (OAK-8118) Index selected properties to enhance feature vector similarity search results

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8118.
-

bulk close 1.12.0

> Index selected properties to enhance feature vector similarity search results
> -
>
> Key: OAK-8118
> URL: https://issues.apache.org/jira/browse/OAK-8118
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0, 1.10.2
>
>
> To improve the accuracy of results of the feature vector similarity search we 
> could include tokens from some configured properties to be treated as 
> keywords or tags.
> Such tags would be used in the query to reduce the number of false positives 
> and improve the precision of search results.



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


[jira] [Closed] (OAK-8013) [Direct Binary Access] DataRecordDownloadOptions creates invalid Content-Disposition headers - Workaround

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8013.
-

bulk close 1.12.0

> [Direct Binary Access] DataRecordDownloadOptions creates invalid 
> Content-Disposition headers - Workaround
> -
>
> Key: OAK-8013
> URL: https://issues.apache.org/jira/browse/OAK-8013
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob-plugins
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.12.0, 1.10.2
>
>
> DataRecordDownloadOptions always adds the extended parameter filename* to the 
> header, [without any 
> escaping|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/directaccess/DataRecordDownloadOptions.java#L130].
> Such extended parameters must not include spaces (and only a small predefined 
> list of basic ascii chars), otherwise they have to be percent encoded. The 
> RFC is https://tools.ietf.org/html/rfc5987 and note the definition of 
> value-chars in the grammar.
> Because of this, if a filename includes a space or another character that 
> must be percent encoded, this currently creates an invalid header that fails 
> to be parsed by other clients.
> See also https://github.com/jshttp/content-disposition/issues/24
>  



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


[jira] [Closed] (OAK-8020) Create ImmutableACL from another AbstractAccessControlList

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8020.
-

bulk close 1.12.0

> Create ImmutableACL from another AbstractAccessControlList
> --
>
> Key: OAK-8020
> URL: https://issues.apache.org/jira/browse/OAK-8020
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
>
> in order to make an existing {{AbstractAccessControlList}} immutable it would 
> be handy to have a separate constructor like e.g. the following:
> {code}
> public ImmutableACL(@NotNull AbstractAccessControlList accessControlList) {
> this(accessControlList.getOakPath(), accessControlList.getEntries(), 
> accessControlList.getRestrictionProvider(), 
> accessControlList.getNamePathMapper());
> }
> {code}
> [~stillalex], fyi



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


[jira] [Closed] (OAK-7986) Incorrect MongoDB URI in ReplicaSetDefaultWriteConcernIT

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7986.
-

bulk close 1.12.0

> Incorrect MongoDB URI in ReplicaSetDefaultWriteConcernIT
> 
>
> Key: OAK-7986
> URL: https://issues.apache.org/jira/browse/OAK-7986
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: mongomk
>Affects Versions: 1.10.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0
>
>
> The ReplicaSetDefaultWriteConcernIT uses an incorrect MongoDB URI to connect 
> to the test replica-set.



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


[jira] [Closed] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8114.
-

bulk close 1.12.0

> IndexDefinitionBuilder should be smarter when to reindex while updating a 
> definition
> 
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>  Labels: candidate_oak_1_10, candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12.0
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an 
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There 
> are quite a few properties which only affect querying or cost-estimation and 
> don't imply a change in indexed data. For such cases, simply setting 
> {{refresh=true}} should suffice.



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


[jira] [Closed] (OAK-8022) Update Oak trunk to Jackrabbit 2.19.0

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8022.
-

bulk close 1.12.0

> Update Oak trunk to Jackrabbit 2.19.0
> -
>
> Key: OAK-8022
> URL: https://issues.apache.org/jira/browse/OAK-8022
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12.0
>
>




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


[jira] [Closed] (OAK-8168) Improve readability of AccessControlAction

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8168.
-

bulk close 1.12.0

> Improve readability of AccessControlAction
> --
>
> Key: OAK-8168
> URL: https://issues.apache.org/jira/browse/OAK-8168
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: OAK-8168.patch
>
>
> [~stillalex], while working on a poc i came across the 
> {{AccessControlAction}} again and found it a bit hard to read. I would 
> appreciate if you could review the attached refactoring. Feedback welcome.



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


[jira] [Closed] (OAK-8094) JMX monitoring to detect commits carrying over from previous GC generation can block other threads from committing

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8094.
-

bulk close 1.12.0

> JMX monitoring to detect commits carrying over from previous GC generation 
> can block other threads from committing
> --
>
> Key: OAK-8094
> URL: https://issues.apache.org/jira/browse/OAK-8094
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Fix For: 1.12.0
>
>
> This is a follow up of OAK-8071 to implement JMX monitoring to detect the 
> situation from OAK-8014.



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


[jira] [Closed] (OAK-8171) Remove DocumentNodeState.getId()

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8171.
-

bulk close 1.12.0

> Remove DocumentNodeState.getId()
> 
>
> Key: OAK-8171
> URL: https://issues.apache.org/jira/browse/OAK-8171
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Trivial
> Fix For: 1.12.0
>
>
> The method is only used in one test class and the return value can be 
> constructed with the help of other methods.



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


[jira] [Closed] (OAK-7924) Reduce Lucene index size footprint with compressing Codec

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7924.
-

bulk close 1.12.0

> Reduce Lucene index size footprint with compressing Codec
> -
>
> Key: OAK-7924
> URL: https://issues.apache.org/jira/browse/OAK-7924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-7924.0.patch
>
>
> In OAK-5192 I had developed a test codec to benchmark all possible space 
> savings options before diving into a custom {{MergePolicy}}.
> The codec developed back then could be used to reduce the index size 
> footprint both on disk and on node store implementations.



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


[jira] [Closed] (OAK-7991) Composite node store: tests with queries

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7991.
-

bulk close 1.12.0

> Composite node store: tests with queries
> 
>
> Key: OAK-7991
> URL: https://issues.apache.org/jira/browse/OAK-7991
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite, indexing
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-7991-a.patch, OAK-7991-b.patch
>
>
> Right now there seem to be no tests that run queries and use the composite 
> node store. This is dangerous, as a lot of code is not tested. Also, it 
> prevents refactoring and adding new features.
> We have seen quite many problems in this area lately, for example:
> * creating indexes with a composite nodestore didn't work
> * changing the Lucene index to lazily load the index files doesn't work



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


[jira] [Closed] (OAK-8091) Build failure: artifact does not exist on remote repository

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8091.
-

bulk close 1.12.0

> Build failure: artifact does not exist on remote repository
> ---
>
> Key: OAK-8091
> URL: https://issues.apache.org/jira/browse/OAK-8091
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
> Fix For: 1.12.0
>
>
> No description is provided
> The build Jackrabbit Oak #1979 has failed.
> First failed run: [Jackrabbit Oak 
> #1979|https://builds.apache.org/job/Jackrabbit%20Oak/1979/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1979/console]
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.felix:maven-bundle-plugin:3.5.1:baseline (baseline) on project 
> oak-commons: Artifact org.apache.jackrabbit:oak-commons:bundle:1.10.1:compile 
> does not exist on local/remote repositories: Could not find artifact 
> org.apache.jackrabbit:oak-commons:jar:1.10.1 in central 
> (https://repo.maven.apache.org/maven2)
> {noformat}



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


[jira] [Closed] (OAK-8113) Add ability to push metrics to prometheus pushgateway from oak-run

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8113.
-

bulk close 1.12.0

> Add ability to push metrics to prometheus pushgateway from oak-run
> --
>
> Key: OAK-8113
> URL: https://issues.apache.org/jira/browse/OAK-8113
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: oak-run
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-8113.patch, OAK-8113_v2.patch
>
>
> Currently, metrics capturing is supported in oak-run but these are not 
> exported. If some important tasks like DSGC are run outside of the server 
> using oak-run then it would be helpful help if these important metrics 
> captured, can be pushed to an external system if available and from where any 
> reporting can be developed.
> This task is specifically meant for prometheus pushgateway 
> https://github.com/prometheus/client_java though there are some other export 
> options also available.



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


[jira] [Closed] (OAK-8169) Missing nullability annotations with UserPrincipalProvider and PrincipalProviderImpl

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8169.
-

bulk close 1.12.0

> Missing nullability annotations with UserPrincipalProvider and 
> PrincipalProviderImpl
> 
>
> Key: OAK-8169
> URL: https://issues.apache.org/jira/browse/OAK-8169
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.12.0
>
> Attachments: OAK-8169.patch
>
>
> [~stillalex], the recently introduced methods to find principals including 
> offset/limit lack some of the nullable/notnull annotations in the 
> {{UserPrincipalProvider}} and {{PrincipalProviderImpl}} implementations. if 
> you don't mind, i would go ahead and add those (see attached patch).



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


[jira] [Closed] (OAK-8092) The cold standby server cannot handle blob requests for long blob IDs

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8092.
-

bulk close 1.12.0

> The cold standby server cannot handle blob requests for long blob IDs
> -
>
> Key: OAK-8092
> URL: https://issues.apache.org/jira/browse/OAK-8092
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, tarmk-standby
>Affects Versions: 1.10.1
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: cold-standby
> Fix For: 1.12.0, 1.10.2
>
> Attachments: OAK-8092.patch
>
>
> If the standby client issues a request for a binary ID larger than 8192 
> bytes, it will fail on the server side due to the current frame limitation, 
> set to 8192 bytes:
> {noformat}
> 28.02.2019 00:01:36.034 *WARN* [primary-32] 
> org.apache.jackrabbit.oak.segment.standby.server.ExceptionHandler Exception 
> caught on the server
> io.netty.handler.codec.TooLongFrameException: frame length (35029) exceeds 
> the allowed maximum (8192)
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:146)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.fail(LineBasedFrameDecoder.java:142)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:131)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.handler.codec.LineBasedFrameDecoder.decode(LineBasedFrameDecoder.java:75)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) 
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
>  [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) 
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) 
> [org.apache.jackrabbit.oak-segment-tar:1.10.1]
> at 
> 

[jira] [Closed] (OAK-8103) TimingHookTest.commitTime failing occasionally

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8103.
-

bulk close 1.12.0

> TimingHookTest.commitTime failing occasionally
> --
>
> Key: OAK-8103
> URL: https://issues.apache.org/jira/browse/OAK-8103
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: documentmk
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.12.0
>
>
> {noformat}
> [ERROR] Failures:
> [ERROR]   TimingHookTest.commitTime:42
> Expected: a value equal to or greater than <10L>
>  but: <9L> was less than <10L>
> {noformat}
> (might be specific to Windows)



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


[jira] [Closed] (OAK-8117) NPE when adding ACE with restrictions and remapped namespaces

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8117.
-

bulk close 1.12.0

> NPE when adding ACE with restrictions and remapped namespaces
> -
>
> Key: OAK-8117
> URL: https://issues.apache.org/jira/browse/OAK-8117
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-8117-test.patch, OAK-8117.patch
>
>
> [~stillalex], just ran into an NPE when adding an ACE including some 
> restriction. The reason is a tiny bug in the {{ACL}} implementation that 
> mistakenly uses the _oakName_ to retrieve the value/values from the passed 
> restriction map. It should obviously use the key of the map, which 
> corresponds to the _jcrName_. in other words: the bug only shows up when 
> running tests with re-mapped namespaces.
> proposed fix attached. will attach a test case illustrating the issue later 
> on.



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


[jira] [Closed] (OAK-8096) CompositeAccessControlManager: misleading local field name

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8096.
-

bulk close 1.12.0

> CompositeAccessControlManager: misleading local field name
> --
>
> Key: OAK-8096
> URL: https://issues.apache.org/jira/browse/OAK-8096
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.12.0
>
>
> the {{CompositeAccessControlManager}} contains methods that collect policies 
> from the aggregated ac-mgr implementations. unfortunately the local fields 
> have a misleading name. should rather be 'policies' than 'privs'.
> [~stillalex], fyi



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


[jira] [Closed] (OAK-8031) Update Oak trunk to Jackrabbit 2.19.1

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8031.
-

bulk close 1.12.0

> Update Oak trunk to Jackrabbit 2.19.1
> -
>
> Key: OAK-8031
> URL: https://issues.apache.org/jira/browse/OAK-8031
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.12.0
>
>




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


[jira] [Closed] (OAK-8125) PrincipalProviderImpl support for range search

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8125.
-

bulk close 1.12.0

> PrincipalProviderImpl support for range search
> --
>
> Key: OAK-8125
> URL: https://issues.apache.org/jira/browse/OAK-8125
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: principal-management-extensions
> Fix For: 1.12.0
>
>
> The {{PrincipalProviderImpl}} related changes for OAK-7994.



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


[jira] [Closed] (OAK-8093) AccessControlManagerImpl: respect local namespaces when writing back ACEs

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8093.
-

bulk close 1.12.0

> AccessControlManagerImpl: respect local namespaces when writing back ACEs
> -
>
> Key: OAK-8093
> URL: https://issues.apache.org/jira/browse/OAK-8093
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: OAK-8093.patch
>
>
> [~stillalex], i noticed that the {{AccessControlManager}} doesn't properly 
> handle local namespaces when writing back ACEs. This may lead to 
> {{CommitFailedException}} or incomplete permission setup.
> Patch for review will follow as well as tests illustrating the issue.



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


[jira] [Closed] (OAK-8024) oak-http generates invalid html

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8024.
-

bulk close 1.12.0

> oak-http generates invalid html 
> 
>
> Key: OAK-8024
> URL: https://issues.apache.org/jira/browse/OAK-8024
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: oak-http
>Reporter: Ruben Reusser
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: oak-http-fixes.patch
>
>
> when using oak-http to explore a repository invalid html is rendered. The 
> title tag is rendered as  causing the generated html to be invalid. 
> This is due to a depricated api usage in oak-http
> please find attached a patch for this issue



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


[jira] [Closed] (OAK-8176) Inaccurate calculation of RevisionVector memory

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8176.
-

bulk close 1.12.0

> Inaccurate calculation of RevisionVector memory
> ---
>
> Key: OAK-8176
> URL: https://issues.apache.org/jira/browse/OAK-8176
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0
>
>
> The calculation of the memory usage for a RevisionVector object is not 
> accurate.



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


[jira] [Closed] (OAK-8078) UserPrincipalProvider support for range search

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8078.
-

bulk close 1.12.0

> UserPrincipalProvider support for range search
> --
>
> Key: OAK-8078
> URL: https://issues.apache.org/jira/browse/OAK-8078
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: principal-management-extensions
> Fix For: 1.12.0
>
> Attachments: OAK-80778.patch
>
>
> The {{UserPrincipalProvider}} related changes for OAK-7994.



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


[jira] [Closed] (OAK-8066) Nodes with many direct children can lead to OOME when saving

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8066.
-

bulk close 1.12.0

> Nodes with many direct children can lead to OOME when saving
> 
>
> Key: OAK-8066
> URL: https://issues.apache.org/jira/browse/OAK-8066
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
>  Labels: TarMK
> Fix For: 1.12.0
>
>
> {{DefaultSegmentWriter}} keeps a map of [child 
> nodes|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriter.java#L805]
>  of a node being written. This can lead to high memory consumption in the 
> case where many child nodes are added at the same time. The latter could 
> happen in the case where a node needs to be rewritten because of an increase 
> in the GC generation from a concurrently completed revision garbage 
> collection.



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


[jira] [Closed] (OAK-8206) Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable Oak release

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8206.
-

bulk close 1.12.0

> Revert Jackrabbit dependency from 2.19.1 to last stable (2.18.0) for stable 
> Oak release
> ---
>
> Key: OAK-8206
> URL: https://issues.apache.org/jira/browse/OAK-8206
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Blocker
> Fix For: 1.12.0
>
>




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


[jira] [Closed] (OAK-8163) examples: update Tomcat dependency to 7.0.93

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8163.
-

bulk close 1.12.0

> examples: update Tomcat dependency to 7.0.93
> 
>
> Key: OAK-8163
> URL: https://issues.apache.org/jira/browse/OAK-8163
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: examples
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_10
> Fix For: 1.12.0
>
>




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


[jira] [Closed] (OAK-8085) Upgrade spotbugs to 3.1.11

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8085.
-

bulk close 1.12.0

> Upgrade spotbugs to 3.1.11
> --
>
> Key: OAK-8085
> URL: https://issues.apache.org/jira/browse/OAK-8085
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6, jdk11
> Fix For: 1.12.0, 1.10.2, 1.8.13
>
>
> ...due to a Java 11 incompatibility:
> {noformat}
>  [java] The following errors occurred during analysis:
>  [java]   Error scanning java/lang/Throwable for referenced classes
>  [java] java.lang.UnsupportedOperationException
>  [java]   At 
> org.objectweb.asm.ClassVisitor.visitNestMemberExperimental(ClassVisitor.java:248)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:651)
>  [java]   At 
> edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44)
>  [java]   At 
> org.objectweb.asm.ClassReader.accept(ClassReader.java:391)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:519)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:703)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:79)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38)
>  [java]   At 
> edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:262)
>  [java]   At 
> edu.umd.cs.findbugs.FindBugs2.buildReferencedClassSet(FindBugs2.java:774)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:220)
>  [java]   At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:401)
>  [java]   At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1185)
> {noformat}



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


[jira] [Closed] (OAK-8120) Update http components to 4.5.7/4.4.11

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8120.
-

bulk close 1.12.0

> Update http components to 4.5.7/4.4.11
> --
>
> Key: OAK-8120
> URL: https://issues.apache.org/jira/browse/OAK-8120
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_6
> Fix For: 1.12.0, 1.8.13, 1.10.3
>
>




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


[jira] [Closed] (OAK-8172) Basic test for LoggingDocumentStoreWrapper

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8172.
-

bulk close 1.12.0

> Basic test for LoggingDocumentStoreWrapper
> --
>
> Key: OAK-8172
> URL: https://issues.apache.org/jira/browse/OAK-8172
> Project: Jackrabbit Oak
>  Issue Type: Test
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0
>
>
> Add a basic test for the LoggingDocumentStoreWrapper. The class currently 
> does not have any test coverage.



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


[jira] [Closed] (OAK-8134) Index Copier Stats MBean shows stale info

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8134.
-

bulk close 1.12.0

> Index Copier Stats MBean shows stale info
> -
>
> Key: OAK-8134
> URL: https://issues.apache.org/jira/browse/OAK-8134
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: indexing
>Affects Versions: 1.12.0
>Reporter: Mohit Kataria
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: 
> 0001-OAK-8134-Index-Copier-Stats-MBean-shows-stale-info.patch, 
> 0002-OAK-8134-Index-Copier-Stats-MBean-shows-stale-info.patch
>
>
>  In cases an index is re-indexed, but indexing is stopped in between, the 
> index copier mbean shows the partially created new index stats even though 
> old indexes are still in use.
> 1. Reindex by setting reindex= true
> 2. stop reindexing using from jmx console (indexstats) as follows:
>  * :/system/console/jmx
>  * click on index's "index stats" whose reindexing is triggered.
>  * call abortAndPause operation. 
>  



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


[jira] [Closed] (OAK-8112) Change log pattern to have complete date for oak-run datastore command

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8112.
-

bulk close 1.12.0

> Change log pattern to have complete date for oak-run datastore command
> --
>
> Key: OAK-8112
> URL: https://issues.apache.org/jira/browse/OAK-8112
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: oak-run
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.12.0, 1.10.2
>
>




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


[jira] [Closed] (OAK-7961) LSH should truncate to first decimal place

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7961.
-

bulk close 1.12.0

> LSH should truncate to first decimal place
> --
>
> Key: OAK-7961
> URL: https://issues.apache.org/jira/browse/OAK-7961
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.12.0
>
>
> Feature vector shingles currently contain three decimal places, e.g. _[0.101, 
> 0.202, 0.303]_.
> Since min hash is not aware of the fact that second and third decimal place 
> values are less important than first place values, it is likely that this 
> will impact the search precision.
> We should be truncating to the first decimal place.



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


[jira] [Closed] (OAK-8095) VersionStorageEditor can prevent upgrade of version store

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8095.
-

bulk close 1.12.0

> VersionStorageEditor can prevent upgrade of version store
> -
>
> Key: OAK-8095
> URL: https://issues.apache.org/jira/browse/OAK-8095
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.10.0, 1.10.1
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.12.0, 1.10.2
>
>
> Followup of OAK-7532, the code that detects an initial startup can miss some 
> setups, failing legal commits like upgrades.
> So far it looks like this only affects direct Oak 1.0 -> 1.10 upgrades, in 
> cases where the version store has some data at the moment of the upgrade.



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


[jira] [Closed] (OAK-8175) ExternalGroupPrincipalProvider support for full text search

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8175.
-

bulk close 1.12.0

> ExternalGroupPrincipalProvider support for full text search
> ---
>
> Key: OAK-8175
> URL: https://issues.apache.org/jira/browse/OAK-8175
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: auth-external, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: principal-management-extensions
> Fix For: 1.12.0
>
>
> The {{ExternalGroupPrincipalProvider}} related changes for OAK-8131.



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


[jira] [Closed] (OAK-8121) RDBExport should handle db2 dump where del files refers to lob files without offset and length params

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8121.
-

bulk close 1.12.0

> RDBExport should handle db2 dump where del files refers to lob files without 
> offset and length params
> -
>
> Key: OAK-8121
> URL: https://issues.apache.org/jira/browse/OAK-8121
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: rdbmk, run
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.12.0
>
>




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


[jira] [Closed] (OAK-8142) CompositePrincipalProvider support for full text search

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8142.
-

bulk close 1.12.0

> CompositePrincipalProvider support for full text search
> ---
>
> Key: OAK-8142
> URL: https://issues.apache.org/jira/browse/OAK-8142
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security, security-spi
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: principal-management-extensions
> Fix For: 1.12.0
>
>
> The {{CompositePrincipalProvider}} related changes for OAK-8131.



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


[jira] [Closed] (OAK-8083) RDB*Store: add SQLServer specific documentation

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8083.
-

bulk close 1.12.0

> RDB*Store: add SQLServer specific documentation
> ---
>
> Key: OAK-8083
> URL: https://issues.apache.org/jira/browse/OAK-8083
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc, rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.12.0, 1.10.3
>
>




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


[jira] [Closed] (OAK-7731) Order by jcr:score descending is not always ignored

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7731.
-

bulk close 1.12.0

> Order by jcr:score descending is not always ignored
> ---
>
> Key: OAK-7731
> URL: https://issues.apache.org/jira/browse/OAK-7731
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Affects Versions: 1.6.9
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: 
> 0001-OAK-7731-Order-by-jcr-score-descending-is-not-always.patch
>
>
> XPath union queries that contain "order by @jcr:score descending" actually do 
> order by jcr:score, which is unexpected.
> This is a bit related to OAK-7131.



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


[jira] [Closed] (OAK-8019) Replace deprecated NodeUtil in AbstractOakCoreTest

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8019.
-

bulk close 1.12.0

> Replace deprecated NodeUtil in AbstractOakCoreTest
> --
>
> Key: OAK-8019
> URL: https://issues.apache.org/jira/browse/OAK-8019
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Fix For: 1.12.0
>
>
> while working on OAK-7997 i noticed that 
> _org.apache.jackrabbit.oak.security.authorization.evaluation.AbstractOakCoreTest_
>  still uses the deprecated {{NodeUtil}}. Replacing by {{TreeUtil}} should be 
> straight forward.
> [~stillalex], fyi



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


[jira] [Closed] (OAK-7976) Non-blocking commit rollback

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7976.
-

bulk close 1.12.0

> Non-blocking commit rollback
> 
>
> Key: OAK-7976
> URL: https://issues.apache.org/jira/browse/OAK-7976
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.12.0
>
>
> When a commit fails e.g. due to a conflict, the changes are rolled back while 
> still holding the commit revision. This causes an unnecessary delay for other 
> commits because at this point it is certain that the revision associated with 
> the rolled back changes will never commit.
> The current implementation is also inefficient because it rolls back the 
> changes one document at a time.



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


[jira] [Closed] (OAK-8108) Branch reset does not remove all branch commit entries

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8108.
-

bulk close 1.12.0

> Branch reset does not remove all branch commit entries
> --
>
> Key: OAK-8108
> URL: https://issues.apache.org/jira/browse/OAK-8108
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: documentmk
>Affects Versions: 1.8.0, 1.10.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0, 1.10.2, 1.8.13
>
>
> Some branch commit entries are not removed on a branch reset. Those are the 
> entries that are  put on the parent of an added node.
> Branch commit entries were added with OAK-5869.



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


[jira] [Closed] (OAK-7027) Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7027.
-

bulk close 1.12.0

> Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
> 
>
> Key: OAK-7027
> URL: https://issues.apache.org/jira/browse/OAK-7027
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar, tarmk-standby
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Major
>  Labels: test-failure
> Fix For: 1.12.0
>
> Attachments: OAK-7027-01.patch, OAK-7027-02.patch
>
>
> Seen on an internal Windows Jenkins node:
> h3. Regression
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
> h3. Error Message
> {noformat}
> Values should be different. Actual: { root = { ... } }
> {noformat}
> h3. Stacktrace
> {noformat}
> java.lang.AssertionError: Values should be different. Actual: { root = { ... 
> } }
>   at 
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout(ExternalPrivateStoreIT.java:87)
> {noformat}
> h3. Standard Output
> {noformat}
> 22:41:13.646 INFO  [main] FileStoreBuilder.java:340 Creating file 
> store FileStoreBuilder{version=1.8-SNAPSHOT, 
> directory=target\junit2834122541179880349\junit3041268421527563090, 
> blobStore=DataStore backed BlobStore 
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1, 
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0, 
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000, 
> nodeDeduplicationCacheSize=1, memoryMapping=false, 
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false, 
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60, 
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO  [main] FileStore.java:241TarMK opened at 
> target\junit2834122541179880349\junit3041268421527563090, mmap=false, size=0 
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files: 
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit3041268421527563090\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment 
> 4cea1684-ef05-44f5-a869-3ef2df6e0c9a to 
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.646 INFO  [main] FileStoreBuilder.java:340 Creating file 
> store FileStoreBuilder{version=1.8-SNAPSHOT, 
> directory=target\junit2834122541179880349\junit4470899745425503556, 
> blobStore=DataStore backed BlobStore 
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1, 
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0, 
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000, 
> nodeDeduplicationCacheSize=1, memoryMapping=false, 
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false, 
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60, 
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO  [main] FileStore.java:241TarMK opened at 
> target\junit2834122541179880349\junit4470899745425503556, mmap=false, size=0 
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files: 
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit4470899745425503556\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment 
> 8d19c7dc-8b48-4e10-a58d-31c15c93f2fe to 
> target\junit2834122541179880349\junit4470899745425503556\data0a.tar
> 22:41:13.646 INFO  [main] DataStoreTestBase.java:127Test begin: 
> testSyncFailingDueToTooShortTimeout
> 22:41:13.646 INFO  [main] SegmentNodeStore.java:120 Creating segment 
> node store SegmentNodeStoreBuilder{blobStore=DataStore backed BlobStore 
> [org.apache.jackrabbit.core.data.FileDataStore]}
> 22:41:13.646 INFO  [main] LockBasedScheduler.java:155   Initializing 
> SegmentNodeStore with the commitFairLock option enabled.
> 22:41:13.708 DEBUG [main] StandbyServer.java:248Binding was 
> successful
> 22:41:13.708 DEBUG [main] TarWriter.java:185Writing segment 
> 4a5183bd-bcdf-41ab-a557-6f19143bbc91 to 
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.739 DEBUG [main] TarRevisions.java:240 TarMK journal 
> update null -> 4a5183bd-bcdf-41ab-a557-6f19143bbc91.000c
> 22:41:13.755 DEBUG [standby-1] GetHeadRequestEncoder.java:33 Sending request 
> from client 9aa63ed8-347b-4f00-ae7c-f984e0623e90 for current head
> 22:41:13.755 DEBUG [primary-1] ClientFilterHandler.java:53  Client 
> /127.0.0.1:65480 is allowed
> 22:41:13.755 DEBUG [primary-1] 

[jira] [Closed] (OAK-8195) AutoSaveEnabledManager.createSystemUser calls createUser on delegatee

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8195.
-

bulk close 1.12.0

> AutoSaveEnabledManager.createSystemUser calls createUser on delegatee
> -
>
> Key: OAK-8195
> URL: https://issues.apache.org/jira/browse/OAK-8195
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
>
> Calling {{AutoSaveEnabledManager.createSystemUser}} is not correctly 
> delegated to the underlying {{UserManager}} but instead calls {{createUser}}. 
> This essentially makes it impossible to create a system user with autosave 
> configuration option enabled.
> [~stillalex], the fix should be trivial to do... will add some test to make 
> sure it's indeed fixed.



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


[jira] [Closed] (OAK-8116) Expose text extraction metrics as sling metrics

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8116.
-

bulk close 1.12.0

> Expose text extraction metrics as sling metrics
> ---
>
> Key: OAK-8116
> URL: https://issues.apache.org/jira/browse/OAK-8116
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: indexing, oak-search
>Affects Versions: 1.12.0
>Reporter: Mohit Kataria
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: 
> 0001-OAK-8116-Expose-text-extraction-metrics-as-sling-met.patch
>
>
> We want to expose Text extraction stats as sling metrics (time metrics).



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


[jira] [Closed] (OAK-8053) Add intermediate report to ExternalLoginTest

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8053.
-

bulk close 1.12.0

> Add intermediate report to ExternalLoginTest
> 
>
> Key: OAK-8053
> URL: https://issues.apache.org/jira/browse/OAK-8053
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Trivial
> Fix For: 1.12.0
>
>
> Add support for a {{report}} flag that will output some intermediary stats 
> (like duration over the last 1k tests).



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


[jira] [Closed] (OAK-8124) Sidegrade operation doesn't run security-related commit hooks

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8124.
-

bulk close 1.12.0

> Sidegrade operation doesn't run security-related commit hooks
> -
>
> Key: OAK-8124
> URL: https://issues.apache.org/jira/browse/OAK-8124
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: upgrade
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.12.0, 1.10.2, 1.8.13
>
> Attachments: OAK-8124-2.patch, OAK-8124.patch
>
>
> It seems that for the partial Oak->Oak migrations (the ones with --include or 
> --exclude-paths), the ACLs are not processed correctly. The security-related 
> commit hooks are not included in the merge() operation and as a result, the 
> permission store is not populated.
> We need to run the appropriate commit hooks in the sidegrade operation.



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


[jira] [Closed] (OAK-7968) Active deletion of Lucene binaries: configuration option to disable

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7968.
-

bulk close 1.12.0

> Active deletion of Lucene binaries: configuration option to disable
> ---
>
> Key: OAK-7968
> URL: https://issues.apache.org/jira/browse/OAK-7968
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing, lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-7968.patch
>
>
> Active deletion of Lucene binaries (OAK-2808) can be disabled temporarily 
> (OAK-6862), however I don't think there is a simple way to disable it 
> permanently, using a config option (OSGi config / system property). 
> It would be good to have such an option to support the use case where the 
> repository is cloned at runtime, and the clones are started. A workaround is 
> to call the JMX method after startup, but that's a bit inconvenient. It would 
> be best if the config option ensure it's also disabled during startup, even 
> thought it's unlikely that active deletion is scheduled during this startup 
> window (better be on the safe side).



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


[jira] [Closed] (OAK-8025) Improve branch state comparison

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8025.
-

bulk close 1.12.0

> Improve branch state comparison
> ---
>
> Key: OAK-8025
> URL: https://issues.apache.org/jira/browse/OAK-8025
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0
>
>
> Comparing the head of a branch state with revision brX-0-1 with the 
> equivalent trunk state rX-0-1 may lookup changes in the diff cache even 
> though it could tell from the revision itself that there are no changes.



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


[jira] [Closed] (OAK-8009) Remove unused code in NodeDocument

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8009.
-

bulk close 1.12.0

> Remove unused code in NodeDocument
> --
>
> Key: OAK-8009
> URL: https://issues.apache.org/jira/browse/OAK-8009
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.12.0
>
>
> The NodeDocument class has some unused code which can be removed.



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


[jira] [Closed] (OAK-7997) Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7997.
-

bulk close 1.12.0

> Adding restrictions to ACLs yields empty results for queries in Jackrabbit Oak
> --
>
> Key: OAK-7997
> URL: https://issues.apache.org/jira/browse/OAK-7997
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: query, security
>Affects Versions: 1.10.0, 1.8.10
>Reporter: Søren Jensen
>Assignee: angela
>Priority: Major
> Fix For: 1.12.0
>
> Attachments: OAK-7997-selectorimpl.patch, OAK-7997.patch, 
> OAK-7997_2.patch, OAK-7997_3.patch
>
>
> Using Jackrabbit Oak, I've been attempting to configure security through 
> {{SecurityProvider}} and {{SecurityConfiguration's. In particular, I've been 
> using the restrictions which generally works as expected. However, when 
> dealing with JCR-SQL2}} queries, more gets filtered out than expected.
> *Details*
> It can be reproduced with the repository below.
> {code:java}
> / 
>   node  [nt:unstructured]
>     subnode [nt:unstructured] {code}
> On {{node}}, I add an access control entry with privilege {{JCR_ALL}} for 
> "{{user"}} together with a restriction for {{rep:glob}} -> {{""}}, such that 
> {{user}} do not have access to any children of {{node - in this case, only 
> subnode}}.
> It works as expected when using {{session.getNode}}:
>  * {{session.getNode("/node")}} returns the node
>  * {{session.getNode("/node/subnode")}} throws {{PathNotFoundException}} as 
> expected due to the restriction.
> However, when I execute the following {{JCR-SQL2}} query:
> {code:java}
> SELECT * FROM [nt:unstructured]{code}
> I get *no results back*. Here I would have expected to get {{/node}}, as it 
> is otherwise available when using {{session.getNode}}. Removing the 
> restriction yields the expected result of both _/node_ and _/node/subnode_.
> As discussed with [~anchela] on the _users_ mailing list, this may either be 
> an actual bug, or it is a conscious decision - in which case it would be nice 
> to have it documented for the security.
> *Code for reproducing:*
> The code for reproducing the error is shown below. The "_restrictions"_ map 
> below seems to be the problem, as this is what results in both _/node_ and 
> _/node/subnode_ being filtered out.
>  
> {code:java}
> public static void main(String[] args) throws Exception {
> Repository repository = new Jcr().with(new 
> MySecurityProvider()).createRepository();
> Session session = repository.login(new UserIdCredentials(""));// 
> principal is "SystemPrincipal.INSTANCE"
> // Create nodes
> Node node = session.getRootNode().addNode("node", "nt:unstructured");
> node.addNode("subnode", "nt:unstructured");
> // Add access control entry + restriction
> AccessControlManager acm = session.getAccessControlManager();
> JackrabbitAccessControlList acl = (JackrabbitAccessControlList) acm
> .getApplicablePolicies("/node").nextAccessControlPolicy();
> Privilege[] privileges = new 
> Privilege[]{acm.privilegeFromName(Privilege.JCR_ALL)};
> Map restrictions = new HashMap() 
> {{put("rep:glob", new StringValue(""));}};
> acl.addEntry(new PrincipalImpl("user"), privileges, true, restrictions);
> acm.setPolicy("/node", acl);
> session.save();
> // executes query
> RowIterator rows = repository.login(new 
> UserIdCredentials("user")).getWorkspace().getQueryManager()
> .createQuery("SELECT * FROM [nt:unstructured]", 
> Query.JCR_SQL2).execute().getRows();
> System.out.println("Number of rows: " + rows.getSize());  //Prints 0
> }
> {code}
> *Code for security configuration:*
> The above code makes use of "MySecurityProvider". I do not suspect this to be 
> the root cause, but please let me know if it can be helpful to have. The 
> security provider has the configuration set to 
> "ConfigurationParameters.EMPTY", and it uses all the default implementations 
> present within the Jackrabbit Oak project. The only exception is the 
> _AuthenticationConfiguration_ which uses a custom implementation using 
> pre-authentication:
>  
> {code:java}
> class MyAuthenticationConfiguration extends AuthenticationConfigurationImpl {
> public MyAuthenticationConfiguration(SecurityProvider securityProvider) {
> super(securityProvider);
> }
> @NotNull
> @Override
> public LoginContextProvider getLoginContextProvider(ContentRepository 
> contentRepository) {
> return new LoginContextProvider() {
> @NotNull
> public LoginContext getLoginContext(Credentials credentials, 
> String workspaceName) {
> String userId = ((UserIdCredentials) credentials).getUserId();
> 

[jira] [Closed] (OAK-7988) The node counter jmx bean should show 0 if a node exists

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-7988.
-

bulk close 1.12.0

> The node counter jmx bean should show 0 if a node exists
> 
>
> Key: OAK-7988
> URL: https://issues.apache.org/jira/browse/OAK-7988
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.12.0
>
>
> Right now, the node counter jmx bean doesn't show a result if a node has few 
> children. It also shows doesn't show a result if the node doesn't exists (due 
> to a typo). It would be nice if existing nodes show "0" in this case, for 
> "exists, but has no or few children", as documented.



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


[jira] [Closed] (OAK-8018) Move LazyValue from oak-core to oak-commons

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8018.
-

bulk close 1.12.0

> Move LazyValue from oak-core to oak-commons
> ---
>
> Key: OAK-8018
> URL: https://issues.apache.org/jira/browse/OAK-8018
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: commons, core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
>
> For OAK-7997 it would be good the have the {{LazyValue}} functionality 
> available outside of the oak-core module.
> cc: [~stillalex]



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


[jira] [Closed] (OAK-8151) Let ACE.getPrincipal return principals obtained from PrincipalManager

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8151.
-

bulk close 1.12.0

> Let ACE.getPrincipal return principals obtained from PrincipalManager
> -
>
> Key: OAK-8151
> URL: https://issues.apache.org/jira/browse/OAK-8151
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: OAK-8151.patch
>
>
> [~stillalex], while {{AccessControlEntry.getPrincipal}} does not mandate the 
> that principal is actually obtained from {{PrincipalManager}} it turned out 
> that some UI code actually relies on that implementation detail. 
> we could still reduce the number of queries resulting from looking up 
> principals by name, by making sure we don't read the same principal multiple 
> times, while computing the entries for a given access control list. that 
> might be somewhat of a compromise to reduce the number of lookups while 
> returning the same principals as we did before optimizing the lookup in 
> OAK-7880.



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


[jira] [Closed] (OAK-8178) Document missing support for multiplexing in Cug Authorization

2019-04-15 Thread Davide Giannella (JIRA)


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

Davide Giannella closed OAK-8178.
-

bulk close 1.12.0

> Document missing support for multiplexing in Cug Authorization
> --
>
> Key: OAK-8178
> URL: https://issues.apache.org/jira/browse/OAK-8178
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: authorization-cug, doc
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12.0
>
>
> [~stillalex], i just noticed that the oak documentation doesn't mention the 
> fact that CUG authorization doesn't allow for the supported paths to be 
> located within or contain any non-default mounts.
> for the sake of consistency we might want to add a short hint as we have it 
> for the multiplexing of the permission store.



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


  1   2   >