[jira] [Commented] (OAK-7633) Build Jackrabbit Oak #1544 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7633:
-

Build is still failing.
Failed run: [Jackrabbit Oak 
#1550|https://builds.apache.org/job/Jackrabbit%20Oak/1550/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1550/console]

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



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

[jira] [Resolved] (OAK-7570) [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger resolved OAK-7570.
---
Resolution: Resolved

I'm resolving this issue because the consensus is to register the 
HttpBlobProvider with the Whiteboard and then use it in oak-jcr.

> [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr
> -
>
> Key: OAK-7570
> URL: https://issues.apache.org/jira/browse/OAK-7570
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: jcr
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> Open discussion related to OAK-7569:
> The [original pull request|https://github.com/apache/jackrabbit-oak/pull/88] 
> proposes changes to oak-api, oak-segment-tar, oak-store-document, oak-core, 
> and oak-jcr as well as oak-blob-plugins, oak-blob-cloud, and oak-blob-azure.  
> Would it be possible / better to keep the changes local to the oak-blob-* 
> bundles and avoid making changes throughout the stack?



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

[jira] [Reopened] (OAK-7643) repository.home not correctly set after converting oak-segment-tar to OSGi R6 annotations

[Andrei Dulceanu (JIRA)]

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

Andrei Dulceanu reopened OAK-7643:
--

[~frm], since you came up with the original fix for OAK-6770, could you take 
another look at what causes the attribute(s) to be wrongfully set with OSGiR6? 

> repository.home not correctly set after converting oak-segment-tar to OSGi R6 
> annotations
> -
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: 1.9.5
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: osgi
> Fix For: 1.9.6
>
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Resolved] (OAK-7573) [DirectBinaryAccess][DISCUSS] Interchangeability directly between ReferenceBinary and Blob

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger resolved OAK-7573.
---
Resolution: Resolved

> [DirectBinaryAccess][DISCUSS] Interchangeability directly between 
> ReferenceBinary and Blob
> --
>
> Key: OAK-7573
> URL: https://issues.apache.org/jira/browse/OAK-7573
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> The [original pull request|https://github.com/apache/jackrabbit-oak/pull/88] 
> adds functionality to ValueFactoryImpl to convert between ReferenceBinary and 
> Blob instances as code paths move through different layers of the 
> application.  Instead of making changes to ValueFactoryImpl should we just 
> enhance the classes themselves, to easily convert from e.g. ReferenceBinary 
> directly to Blob?



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

[jira] [Commented] (OAK-7589) [DirectBinaryAccess][DISCUSS] Client facing API

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7589:
---

I created a Jackrabbit issue we can use to propose the final draft: JCR-4335.

> [DirectBinaryAccess][DISCUSS] Client facing API
> ---
>
> Key: OAK-7589
> URL: https://issues.apache.org/jira/browse/OAK-7589
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> From a discussion w/ [~mreutegg]:  Suggested that we move the API changes out 
> of oak-jcr (i.e. org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryProvider 
> and org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryDownload to a 
> different package to avoid unnecessary API changes to oak-jcr.
> This issue should also be used to discuss how exactly the client facing API 
> is designed. 



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

[jira] [Assigned] (OAK-7643) repository.home not correctly set after converting oak-segment-tar to OSGi R6 annotations

[Andrei Dulceanu (JIRA)]

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

Andrei Dulceanu reassigned OAK-7643:


Assignee: Francesco Mari  (was: Andrei Dulceanu)

> repository.home not correctly set after converting oak-segment-tar to OSGi R6 
> annotations
> -
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: 1.9.5
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
> Fix For: 1.9.6
>
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Resolved] (OAK-7574) [DirectBinaryAccess][DISCUSS] use URI instead of URL

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger resolved OAK-7574.
---
Resolution: Resolved

I'm resolving this issue because the proposed APIs have been changed to use URI.

> [DirectBinaryAccess][DISCUSS] use URI instead of URL
> 
>
> Key: OAK-7574
> URL: https://issues.apache.org/jira/browse/OAK-7574
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: api
>Reporter: Julian Reschke
>Assignee: Matt Ryan
>Priority: Major
>
> Please do not use {{java.net.URL}}:
> 1. It predates java.net.URI and sort of implies concrete client implications
>  2. It has historic baggage such as the incorrect and surprising behavior of 
> {{equals()}} and {{hashCode()}}
>  -3. It's inconsistent with the JCR API which uses {{java.net.URI}}-



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

[jira] [Resolved] (OAK-7643) repository.home not correctly set after converting oak-segment-tar to OSGi R6 annotations

[Andrei Dulceanu (JIRA)]

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

Andrei Dulceanu resolved OAK-7643.
--
Resolution: Fixed

At r1836149 I reverted the changes introduced by OAK-6770.

> repository.home not correctly set after converting oak-segment-tar to OSGi R6 
> annotations
> -
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: 1.9.5
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: osgi
> Fix For: 1.9.6
>
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Commented] (OAK-7642) oak-pojosr fails when run twice

[Andrei Dulceanu (JIRA)]

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

Andrei Dulceanu commented on OAK-7642:
--

OAK-7643 is fixed now. [~reschke], could you please confirm that the problem is 
gone?

> oak-pojosr fails when run twice
> ---
>
> Key: OAK-7642
> URL: https://issues.apache.org/jira/browse/OAK-7642
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: pojosr
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
>
> ...because segment store apparently creates the repository folder in the 
> wrong location, and thus doesn't get wiped out on "mvn clean".
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.ConfigTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2 s - 
> in org.apache.jackrabbit.oak.run.osgi.ConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
> [WARNING] Tests run: 10, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 
> 10.327 s - in org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.HybridIndexDisabledTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.149 
> s - in org.apache.jackrabbit.oak.run.osgi.HybridIndexDisabledTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.475 
> s - in org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.547 
> s - in org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.518 
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> [ERROR] fullTextSearch(org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest)  
> Time elapsed: 0.518 s  <<< ERROR!
> javax.jcr.ItemExistsException: myFile
> at 
> org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest.fullTextSearch(LuceneSupportTest.groovy:65)
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.MBeanIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.522 
> s - in org.apache.jackrabbit.oak.run.osgi.MBeanIntegrationTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.36 s 
> - in org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.545 
> s - in org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.374 
> s <<< FAILURE! - in 
> org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest
> [ERROR] 
> propertyIndexState(org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest)
>   Time elapsed: 6.358 s  <<< ERROR!
> javax.jcr.ItemExistsException: a1
> at 
> org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest.propertyIndexState(PropertyIndexReindexingTest.groovy:50)
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.RepositoryClosedTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.595 
> s - in org.apache.jackrabbit.oak.run.osgi.RepositoryClosedTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.RepositoryShutdownTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.515 
> s - in org.apache.jackrabbit.oak.run.osgi.RepositoryShutdownTest
> [INFO] Running 
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.421 
> s - in org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.703 
> s - in org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.SimpleRepositoryFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.481 
> s - in org.apache.jackrabbit.oak.run.osgi.SimpleRepositoryFactoryTest
> [INFO] Running 
> 

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7637:
---

bq. After discussion Alex and I didn't think we need to support "filename*" for 
the content disposition

Can you elaborate what your thinking was? I'd say it is quite useful when the 
file name has characters not present in ISO-8859-1.

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Created] (OAK-7643) repository.home not correctly set after converting oak-segment-tar to OSGi R6 annotations

[Andrei Dulceanu (JIRA)]

Andrei Dulceanu created OAK-7643:


 Summary: repository.home not correctly set after converting 
oak-segment-tar to OSGi R6 annotations
 Key: OAK-7643
 URL: https://issues.apache.org/jira/browse/OAK-7643
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: segment-tar
Affects Versions: 1.9.5
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
 Fix For: 1.9.6


With the changes from OAK-6770 applied, it seems that {{repository.home}} 
attribute is not correctly set, causing the repository to be written one level 
up in the directory hierarchy from where it was supposed to. 



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

[jira] [Commented] (OAK-7642) oak-pojosr fails when run twice

[Andrei Dulceanu (JIRA)]

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

Andrei Dulceanu commented on OAK-7642:
--

I created OAK-7643 to track the original bug.

> oak-pojosr fails when run twice
> ---
>
> Key: OAK-7642
> URL: https://issues.apache.org/jira/browse/OAK-7642
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: pojosr
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
>
> ...because segment store apparently creates the repository folder in the 
> wrong location, and thus doesn't get wiped out on "mvn clean".
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.ConfigTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2 s - 
> in org.apache.jackrabbit.oak.run.osgi.ConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
> [WARNING] Tests run: 10, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 
> 10.327 s - in org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.HybridIndexDisabledTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.149 
> s - in org.apache.jackrabbit.oak.run.osgi.HybridIndexDisabledTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.475 
> s - in org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.547 
> s - in org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.518 
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> [ERROR] fullTextSearch(org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest)  
> Time elapsed: 0.518 s  <<< ERROR!
> javax.jcr.ItemExistsException: myFile
> at 
> org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest.fullTextSearch(LuceneSupportTest.groovy:65)
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.MBeanIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.522 
> s - in org.apache.jackrabbit.oak.run.osgi.MBeanIntegrationTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.36 s 
> - in org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.545 
> s - in org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.374 
> s <<< FAILURE! - in 
> org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest
> [ERROR] 
> propertyIndexState(org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest)
>   Time elapsed: 6.358 s  <<< ERROR!
> javax.jcr.ItemExistsException: a1
> at 
> org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest.propertyIndexState(PropertyIndexReindexingTest.groovy:50)
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.RepositoryClosedTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.595 
> s - in org.apache.jackrabbit.oak.run.osgi.RepositoryClosedTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.RepositoryShutdownTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.515 
> s - in org.apache.jackrabbit.oak.run.osgi.RepositoryShutdownTest
> [INFO] Running 
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.421 
> s - in org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.703 
> s - in org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.SimpleRepositoryFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.481 
> s - in org.apache.jackrabbit.oak.run.osgi.SimpleRepositoryFactoryTest
> [INFO] Running 
> 

[jira] [Resolved] (OAK-7572) [DirectBinaryAccess][DISCUSS] Support direct access via enhanced binary capabilities

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger resolved OAK-7572.
---
Resolution: Resolved

Agreed, the consensus is to expose the new capabilities in jackrabbit-api as an 
extension to the ValueFactory and the Binary interfaces.

> [DirectBinaryAccess][DISCUSS] Support direct access via enhanced binary 
> capabilities
> 
>
> Key: OAK-7572
> URL: https://issues.apache.org/jira/browse/OAK-7572
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> The proposal in OAK-7569 enables direct upload and download capabilities via 
> API enhancements.  Would it be better instead to take an approach similar to 
> that in OAK-6575 and enable this via enhanced capabilities of a Binary 
> subclass or extension interface?



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

[jira] [Commented] (OAK-7640) Prevent commits in the past

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7640:
---

Proposed changes are here: 
https://github.com/apache/jackrabbit-oak/compare/trunk...mreutegg:OAK-7640

The DocumentNodeStore refuses to start when the lastRev timestamp of the 
current cluster node is newer than the current time.

> Prevent commits in the past
> ---
>
> Key: OAK-7640
> URL: https://issues.apache.org/jira/browse/OAK-7640
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>  Labels: resilience
> Fix For: 1.10
>
>
> This is similar to OAK-3883, but must prevent commits with revisions that are 
> older than already present in the repository. At runtime, this is already 
> taken care of with static fields in the Revision class, but on startup the 
> clock may have jumped into the past since Oak was stopped.



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

[jira] [Commented] (OAK-7511) get rid of JSR 305 dependency - use jetbrains nullability annotations instead

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7511:
---

+1

> get rid of JSR 305 dependency - use jetbrains nullability annotations instead
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7637:
-

Another question: if (some of) the metadata is part of the signed URI, what 
needs to happen when that data changes later on?

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7637:
-

bq. I'd say it is quite useful when the file name has characters not present in 
ISO-8859-1.

How does ISO-8859-1 come into play here?

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Commented] (OAK-7589) [DirectBinaryAccess][DISCUSS] Client facing API

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7589:
---

[~mattvryan], I reviewed your recent changes on 
[github|https://github.com/apache/jackrabbit/compare/trunk...mattvryan:direct-binary-access-with-OAK-7637].

As mentioned by Julian in OAK-7637, 'contentTypeEncoding' should be changed to 
'characterEncoding' or 'encoding'. JCR defines two related properties on a 
{{nt:resource}}: {{jcr:mimeType}} and {{jcr:encoding}}. So, we could also name 
them {{mimeType}} and {{encoding}} in the download options.

Can you please also add some JavaDoc? E.g. mention that encoding is related to 
the content type and only makes sense when the binary is text.

I would also make {{BinaryDownloadOptions}} and 
{{BinaryDownloadOptionsBuilder}} final. WDYT?

> [DirectBinaryAccess][DISCUSS] Client facing API
> ---
>
> Key: OAK-7589
> URL: https://issues.apache.org/jira/browse/OAK-7589
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> From a discussion w/ [~mreutegg]:  Suggested that we move the API changes out 
> of oak-jcr (i.e. org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryProvider 
> and org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryDownload to a 
> different package to avoid unnecessary API changes to oak-jcr.
> This issue should also be used to discuss how exactly the client facing API 
> is designed. 



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

[jira] [Commented] (OAK-7643) repository.home not correctly set after converting oak-segment-tar to OSGi R6 annotations

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7643:
---

I think it would have been better to re-open OAK-6770. The changes didn't go 
into a release yet. Furthermore, OAK-6770 currently indicates those changes 
will be in 1.9.6, which is not the case. The 'affects versions' of this issue 
should also be updated. AFAIU Oak 1.9.5 is not affected.

> repository.home not correctly set after converting oak-segment-tar to OSGi R6 
> annotations
> -
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: 1.9.5
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
> Fix For: 1.9.6
>
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7637:
---

bq. How does ISO-8859-1 come into play here?

My reading of [RFC 6266|https://tools.ietf.org/html/rfc6266#section-4.3] is 
that 'filename' only support ISO-8859-1 characters, while 'filename*' allows 
you to specify a different encoding.



> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Comment Edited] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on OAK-7637 at 7/18/18 10:00 AM:
---

{quote}I will add the ability to specify whether the content disposition should 
be "inline" or "attachment" as well as the filename.  (After discussion Alex 
and I didn't think we need to support "filename*" for the content disposition; 
[~reschke] do you agree?)
{quote}

- who is in the position to decide what the disposition type is? 
- -I thought filename was added to make "save as" behave sanely?-


was (Author: reschke):
{quote}I will add the ability to specify whether the content disposition should 
be "inline" or "attachment" as well as the filename.  (After discussion Alex 
and I didn't think we need to support "filename*" for the content disposition; 
[~reschke] do you agree?)
{quote}

- who is in the position to decide what the disposition type is? 
- I thought filename was added to make "save as" behave sanely?

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Comment Edited] (OAK-7589) [DirectBinaryAccess][DISCUSS] Client facing API

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger edited comment on OAK-7589 at 7/18/18 9:59 AM:


[~mattvryan], I reviewed your recent changes on 
[github|https://github.com/apache/jackrabbit/compare/trunk...mattvryan:direct-binary-access-with-OAK-7637].

As mentioned by Julian in OAK-7637, 'contentTypeEncoding' should be changed to 
'characterEncoding' or 'encoding'. JCR defines two related properties on a 
{{nt:resource}}: {{jcr:mimeType}} and {{jcr:encoding}}. So, we could also name 
them {{mimeType}} and {{encoding}} in the download options.

Can you please also add some JavaDoc to {{BinaryDownloadOptions}} and 
{{BinaryDownloadOptionsBuilder}}? E.g. mention that encoding is related to the 
content type and only makes sense when the binary is text.

I would also make {{BinaryDownloadOptions}} and 
{{BinaryDownloadOptionsBuilder}} final. WDYT?


was (Author: mreutegg):
[~mattvryan], I reviewed your recent changes on 
[github|https://github.com/apache/jackrabbit/compare/trunk...mattvryan:direct-binary-access-with-OAK-7637].

As mentioned by Julian in OAK-7637, 'contentTypeEncoding' should be changed to 
'characterEncoding' or 'encoding'. JCR defines two related properties on a 
{{nt:resource}}: {{jcr:mimeType}} and {{jcr:encoding}}. So, we could also name 
them {{mimeType}} and {{encoding}} in the download options.

Can you please also add some JavaDoc? E.g. mention that encoding is related to 
the content type and only makes sense when the binary is text.

I would also make {{BinaryDownloadOptions}} and 
{{BinaryDownloadOptionsBuilder}} final. WDYT?

> [DirectBinaryAccess][DISCUSS] Client facing API
> ---
>
> Key: OAK-7589
> URL: https://issues.apache.org/jira/browse/OAK-7589
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> From a discussion w/ [~mreutegg]:  Suggested that we move the API changes out 
> of oak-jcr (i.e. org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryProvider 
> and org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryDownload to a 
> different package to avoid unnecessary API changes to oak-jcr.
> This issue should also be used to discuss how exactly the client facing API 
> is designed. 



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

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7637:
-

bq. My reading of RFC 6266 is that 'filename' only support ISO-8859-1 
characters, while 'filename*' allows you to specify a different encoding.

Indeed. I misread the proposal (didn't spot the "*"). So yes, the code should 
use "filename*" (either always or only when needed).

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on OAK-7637:
---

bq. if (some of) the metadata is part of the signed URI, what needs to happen 
when that data changes later on?

The implementation is expected to hand out a signed URI with a TTL. I 
understand, this means a client will later have to get a new URI anyway which 
will reflect the changes in the metadata.

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Resolved] (OAK-7511) get rid of JSR 305 dependency - use jetbrains nullability annotations instead

[Julian Reschke (JIRA)]

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

Julian Reschke resolved OAK-7511.
-
   Resolution: Fixed
Fix Version/s: 1.9.7

> get rid of JSR 305 dependency - use jetbrains nullability annotations instead
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency - use jetbrains nullability annotations instead

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7511:

Labels: candidate_oak_1_8  (was: )

> get rid of JSR 305 dependency - use jetbrains nullability annotations instead
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Commented] (OAK-7511) get rid of JSR 305 dependency - use jetbrains nullability annotations instead

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7511:
-

trunk: [r1836206|http://svn.apache.org/r1836206] 
[r1836196|http://svn.apache.org/r1836196] 
[r1836195|http://svn.apache.org/r1836195] 
[r1836194|http://svn.apache.org/r1836194] 
[r1836193|http://svn.apache.org/r1836193] 
[r1836192|http://svn.apache.org/r1836192] 
[r1836191|http://svn.apache.org/r1836191] 
[r1836190|http://svn.apache.org/r1836190] 
[r1836189|http://svn.apache.org/r1836189] 
[r1836188|http://svn.apache.org/r1836188] 
[r1836187|http://svn.apache.org/r1836187] 
[r1836186|http://svn.apache.org/r1836186] 
[r1836185|http://svn.apache.org/r1836185] 
[r1836184|http://svn.apache.org/r1836184] 
[r1836183|http://svn.apache.org/r1836183] 
[r1836182|http://svn.apache.org/r1836182] 
[r1836181|http://svn.apache.org/r1836181] 
[r1836180|http://svn.apache.org/r1836180] 
[r1836179|http://svn.apache.org/r1836179] 
[r1836178|http://svn.apache.org/r1836178] 
[r1836177|http://svn.apache.org/r1836177] 
[r1836176|http://svn.apache.org/r1836176] 
[r1836175|http://svn.apache.org/r1836175] 
[r1836174|http://svn.apache.org/r1836174] 
[r1836173|http://svn.apache.org/r1836173] 
[r1836172|http://svn.apache.org/r1836172] 
[r1836171|http://svn.apache.org/r1836171] 
[r1836170|http://svn.apache.org/r1836170] 
[r1836168|http://svn.apache.org/r1836168] 
[r1836167|http://svn.apache.org/r1836167]


> get rid of JSR 305 dependency - use jetbrains nullability annotations instead
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Commented] (OAK-7633) Build Jackrabbit Oak #1544 failed

[Hudson (JIRA)]

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

Hudson commented on OAK-7633:
-

Build is still failing.
Failed run: [Jackrabbit Oak 
#1551|https://builds.apache.org/job/Jackrabbit%20Oak/1551/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/1551/console]

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



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

[jira] [Commented] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7637:
-

Ah. Got it.

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download 
> URIs?
> ---
>
> Key: OAK-7637
> URL: https://issues.apache.org/jira/browse/OAK-7637
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud, blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> There are at least three headers that need to be set in responses to direct 
> GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, 
> these headers should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no 
> associated content type.  When a client obtains a download URI and issues a 
> request to that URI, the resulting response should have the {{Content-Type}} 
> header set so that the binary data will be interpreted properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated 
> identifier for the blob, which is not a user-friendly name for the content 
> being represented.  When a client obtains a download URI and issues a request 
> to that URI, the resulting response should have the {{Content-Disposition}} 
> header set to a user-friendly name for that binary.  For example, a PDF 
> document stored in the repository as "TeamGoals.pdf" would have a completely 
> different blob name, and the generated URI to read that PDF directly from 
> storage would also have that unhelpful name.  If the {{Content-Disposition}} 
> header is set, then an end user trying to save the PDF from a web page link 
> would save it using the name returned in the {{Content-Disposition}} header 
> rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is 
> created, it is cacheable, so the {{Cache-Control}} header should be set to 
> allow the binary to be cached.



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

[jira] [Updated] (OAK-7643) Revert changes done by OAK-6770

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated OAK-7643:
--
Issue Type: Technical task  (was: Bug)
Parent: OAK-6741

> Revert changes done by OAK-6770
> ---
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Affects Versions: 1.9.5
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
> Fix For: 1.9.6
>
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Updated] (OAK-7643) Revert changes done by OAK-6770

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated OAK-7643:
--
Summary: Revert changes done by OAK-6770  (was: repository.home not 
correctly set after converting oak-segment-tar to OSGi R6 annotations)

> Revert changes done by OAK-6770
> ---
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: segment-tar
>Affects Versions: 1.9.5
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
> Fix For: 1.9.6
>
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Updated] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated OAK-6770:
--
Fix Version/s: (was: 1.9.6)

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi, technical_debt
> Fix For: 1.10
>
> Attachments: OAK-6770-01.patch
>
>




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

[jira] [Resolved] (OAK-7643) Revert changes done by OAK-6770

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger resolved OAK-7643.
---
Resolution: Done

I resolved this issue and removed the affected and fix version because the 
changes done by OAK-6770 did not go into a release yet.

> Revert changes done by OAK-6770
> ---
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Updated] (OAK-7643) Revert changes done by OAK-6770

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated OAK-7643:
--
Affects Version/s: (was: 1.9.5)

> Revert changes done by OAK-6770
> ---
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Reopened] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Davide Giannella (JIRA)]

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

Davide Giannella reopened OAK-6770:
---

Re-opening as commit reverted as part of OAK-7643

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi, technical_debt
> Fix For: 1.10, 1.9.6
>
> Attachments: OAK-6770-01.patch
>
>




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

[jira] [Updated] (OAK-7643) Revert changes done by OAK-6770

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger updated OAK-7643:
--
Fix Version/s: (was: 1.9.6)

> Revert changes done by OAK-6770
> ---
>
> Key: OAK-7643
> URL: https://issues.apache.org/jira/browse/OAK-7643
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Francesco Mari
>Priority: Major
>  Labels: osgi
>
> With the changes from OAK-6770 applied, it seems that {{repository.home}} 
> attribute is not correctly set, causing the repository to be written one 
> level up in the directory hierarchy from where it was supposed to. 



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

[jira] [Updated] (OAK-7263) oak-lucene should not depend on oak-store-document

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7263:
--
Fix Version/s: 1.9.7

> oak-lucene should not depend on oak-store-document
> --
>
> Key: OAK-7263
> URL: https://issues.apache.org/jira/browse/OAK-7263
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> {{oak-lucene}} has a hard dependency on {{oak-store-document}} and that looks 
> wrong to me. 
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
> (default-compile) on project oak-lucene: Compilation failure: Compilation 
> failure: 
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[31,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[37,46]
>  cannot find symbol
> [ERROR]   symbol: class JournalProperty
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[33,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[34,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[38,47]
>  cannot find symbol
> [ERROR]   symbol: class JournalPropertyBuilder
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[106,12]
>  cannot find symbol
> [ERROR]   symbol:   class JournalProperty
> [ERROR]   location: class 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyBuilder
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java:[55,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[29,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[33,31]
>  cannot find symbol
> [ERROR]   symbol: class JournalProperty
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[22,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[23,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[25,54]
>  cannot find symbol
> [ERROR]   symbol: class JournalPropertyService
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[33,12]
>  cannot find symbol
> [ERROR]   symbol:   class JournalPropertyBuilder
> [ERROR]   location: class 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyService
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[50,5]
>  method does not override or implement a method from a supertype
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[61,5]
>  method does not override or implement a method from a supertype
> [ERROR] 
> 

[jira] [Updated] (OAK-2155) TokenAuthenticationTest#tokenCreationWithPreAuth test failing repeatedly

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-2155:
--
Fix Version/s: 1.9.7

> TokenAuthenticationTest#tokenCreationWithPreAuth test failing repeatedly
> 
>
> Key: OAK-2155
> URL: https://issues.apache.org/jira/browse/OAK-2155
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, pojosr
>Reporter: Amit Jain
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: CI, test, ubuntu
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> The test 
> {{org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest#tokenCreationWithPreAuth}}
>  in oak-pojosr component failing repeatedly on the local system.
> Also, failing repeatedly on http://ci.apache.org/builders/oak-trunk-win7.



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

[jira] [Updated] (OAK-6069) Modularisation of Oak

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6069:
--
Fix Version/s: 1.9.7

> Modularisation of Oak
> -
>
> Key: OAK-6069
> URL: https://issues.apache.org/jira/browse/OAK-6069
> Project: Jackrabbit Oak
>  Issue Type: Epic
>  Components: core
>Reporter: angela
>Priority: Major
>  Labels: modularization
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Epic to track individual steps towards improved modularisation of Oak
> Until now Oak modules are all released together, which has some drawbacks. 
> Work on the modules must be somewhat kept in lockstep. Releasing a fix for a 
> module means all other modules must be in a state that can be released as 
> well. For a user it may be desirable to just update a single module to get a 
> fix and not a complete set of Oak bundles.
> The general approach for this epic should be to modularize only as needed and 
> not split everything. Obvious candidates are stable interfaces like Oak and 
> NodeStore API and NodeStore implementations.
> This requires fixing potential circular dependencies between logical modules 
> we want to split up. We need a better distinction between the interface part 
> of the SPI and its implementations. Utilities and commons code must be 
> reviewed and potentially moved.
> The oak-it related dependencies should be reconsidered and that a development 
> version of a NodeStore implementation can run integration tests. With the 
> current dependency setup a release of the NodeStore implementation is 
> required first to run the integration tests with those changes.
> Some modules will probably be moved to the top-level and have their own 
> branches and tags.
> To avoid branches it is important to always have trunk stable. Feature work 
> must happen on feature branches, in a forked module or protected with a 
> feature flag until it is ready for prime time. No more unstable work in trunk.
> Module owner is primarily responsible for module releases. At some point 
> there won't be a dedicated person anymore responsible for 'the Oak release'.



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

[jira] [Updated] (OAK-5923) Document S3 datastore

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5923:
--
Fix Version/s: 1.9.7

> Document S3 datastore
> -
>
> Key: OAK-5923
> URL: https://issues.apache.org/jira/browse/OAK-5923
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: blob, doc
>Reporter: Alexander Klimetschek
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> The S3 datastore is currently hardly documented.
> The [generic blobstore 
> documentation|http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html] 
> is very much focused about the internal class structures, but quite confusing 
> for someone who wants to configure a specific datastore such as file and s3 
> (the only ones right now). S3 settings are not documented at all, the [config 
> page|http://jackrabbit.apache.org/oak/docs/osgi_config.html#config-blobstore] 
> only mentions the generic maxCachedBinarySize and cacheSizeInMB.
> The best bet is the [Adobe AEM product 
> documentation|https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html],
>  but that is for an older version and a few things changed since then.
> Specific items below. Some have been confusing people using oak-blob-cloud 
> 1.5.15:
> - "secret" property unclear (new)
> - secretKey & accessKey can be omitted to leverage IAM roles (new)
> - drop of proactiveCaching property (new)
> - aws bucket/region/etc. settings
> - config options (timeout, retries, threads)
> - understanding caching behavior and performance optimization
> - shared vs. non-shared options
> - migrating from a previous version, how to update the config
> - requirements on the AWS (account) side



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

[jira] [Updated] (OAK-7358) Remove all usage of java.security.acl.Group for Java 12

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7358:
--
Fix Version/s: 1.9.7

> Remove all usage of java.security.acl.Group for Java 12
> ---
>
> Key: OAK-7358
> URL: https://issues.apache.org/jira/browse/OAK-7358
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Followup of OAK-7024 for the actual removal of the Group class from the 
> codebase to be java 11 compliant.
> Not sure what to use for 'fix version', I went with 1.9.0 so this remains on 
> the radar, but we can push it out as needed.



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

[jira] [Updated] (OAK-3355) Test failure: SpellcheckTest.testSpellcheckMultipleWords

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-3355:
--
Fix Version/s: 1.9.7

> Test failure: SpellcheckTest.testSpellcheckMultipleWords
> 
>
> Key: OAK-3355
> URL: https://issues.apache.org/jira/browse/OAK-3355
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Affects Versions: 1.0.24
> Environment: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: ci, jenkins, test, test-failure
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> {{org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords}}
>  fails on Jenkins.
> Failure seen at builds: 389, 392, 395, 396, 562
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/396/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/console
> {noformat}
> testSpellcheckMultipleWords(org.apache.jackrabbit.oak.jcr.query.SpellcheckTest)
>   Time elapsed: 0.907 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[voting[ in] ontario]> but 
> was:<[voting[, voted,] ontario]>
>   at junit.framework.Assert.assertEquals(Assert.java:85)
>   at junit.framework.Assert.assertEquals(Assert.java:91)
>   at 
> org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords(SpellcheckTest.java:86)
> {noformat}



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

[jira] [Updated] (OAK-6288) Test failure: upgrade tests failing: Failed to copy content

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6288:
--
Fix Version/s: 1.9.7

> Test failure: upgrade tests failing: Failed to copy content
> ---
>
> Key: OAK-6288
> URL: https://issues.apache.org/jira/browse/OAK-6288
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #364 has failed.
> First failed run: [Jackrabbit Oak 
> #364|https://builds.apache.org/job/Jackrabbit%20Oak/364/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/364/console]
> Failing tests:
> {noformat}
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
>  the warning]
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
>  data store defined, checkpoints migrated]
> 
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment-tar -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to embedded, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to external, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to embedded, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}
> All seem to fail with
> {noformat}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.737 
> s <<< FAILURE! - in 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest
> [ERROR] 
> validateMigration(org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest)
>   Time elapsed: 3.73 s  <<< ERROR!
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy 
> content
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> Caused by: java.lang.IllegalArgumentException
> {noformat}



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

[jira] [Updated] (OAK-7577) Update maven plugins from org.apache.maven.plugins

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7577:
--
Fix Version/s: 1.9.7

> Update maven plugins from org.apache.maven.plugins
> --
>
> Key: OAK-7577
> URL: https://issues.apache.org/jira/browse/OAK-7577
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: benchmarks, examples, parent, run, upgrade
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> ...to latest and greatest.



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

[jira] [Updated] (OAK-6166) Support versioning in the federated node store

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6166:
--
Fix Version/s: 1.9.7

> Support versioning in the federated node store
> --
>
> Key: OAK-6166
> URL: https://issues.apache.org/jira/browse/OAK-6166
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> The mount info provider should affect the versioning code as well, so version 
> histories for the mounted paths are stored separately. Similarly to what we 
> have in the indexing, let's store the mounted version histories under:
> /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME



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

[jira] [Updated] (OAK-7607) Update 7.0.* Tomcat dependencies once 7.0.90 is released

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7607:
--
Fix Version/s: 1.9.7

> Update 7.0.* Tomcat dependencies once 7.0.90 is released
> 
>
> Key: OAK-7607
> URL: https://issues.apache.org/jira/browse/OAK-7607
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent, webapp
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, 
> candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.10, 1.9.6, 1.9.7
>
>




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

[jira] [Updated] (OAK-7639) Surface more DSGC operation stats

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7639:
--
Fix Version/s: 1.9.7

> Surface more DSGC operation stats 
> --
>
> Key: OAK-7639
> URL: https://issues.apache.org/jira/browse/OAK-7639
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob-plugins
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> The current metrics being pushed like should also be surfaced through the 
> MarkSweepGarbageCollector object :
> * Candidates found
> * Blobs deleted
> * Total approx. size deleted



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

[jira] [Updated] (OAK-3809) Test failure: FacetTest

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-3809:
--
Fix Version/s: 1.9.7

> Test failure: FacetTest
> ---
>
> Key: OAK-3809
> URL: https://issues.apache.org/jira/browse/OAK-3809
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
> Environment: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: ci, jenkins, test, test-failure
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> {{org.apache.jackrabbit.oak.jcr.query.FacetTest}} keeps failing on Jenkins:
> {noformat}
> testFacetRetrievalMV(org.apache.jackrabbit.oak.jcr.query.FacetTest)  Time 
> elapsed: 5.927 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected: (2), aem (1), apache (1), cosmetics (1), furniture (1)], tags:[repository 
> (2), software (2), aem (1), apache (1), cosmetics (1), furniture (1)], 
> tags:[repository (2), software (2), aem (1), apache (1), cosmetics (1), 
> furniture (1)], tags:[repository (2), software (2), aem (1), apache (1), 
> cosmetics (1), furniture (1)]]> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:100)
>   at junit.framework.Assert.assertEquals(Assert.java:107)
>   at junit.framework.TestCase.assertEquals(TestCase.java:269)
>   at 
> org.apache.jackrabbit.oak.jcr.query.FacetTest.testFacetRetrievalMV(FacetTest.java:80)
> {noformat}
> Failure seen at builds: 628, 629, 630, 633, 634, 636, 642, 643, 644, 645, 
> 648, 651, 656, 659, 660, 663, 666
> See e.g. 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/634/#showFailuresLink



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

[jira] [Updated] (OAK-7074) Ensure that all Documents are read with document order traversal indexing

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7074:
--
Fix Version/s: 1.9.7

> Ensure that all Documents are read with document order traversal indexing
> -
>
> Key: OAK-7074
> URL: https://issues.apache.org/jira/browse/OAK-7074
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> With OAK-6353 support was added for document order traversal indexing. In 
> this mode we open a DB cursor and try to read all documents from it using 
> document order traversal. Such a cursor may remain open for long time (2-4 
> hrs) and its possible that document may get reordered by the Mongo storage 
> engine. This would result in 2 aspects to be thought about 
> # Duplicate documents - Same document may appear more than once in result set 
> # Possibly missed document - It may be a possibility that a document got 
> moved and missed becoming part of cursor. 
> Both these aspects would need to be handled



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

[jira] [Updated] (OAK-3437) Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when enabling OAK-1617

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-3437:
--
Fix Version/s: 1.9.7

> Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when 
> enabling OAK-1617
> --
>
> Key: OAK-3437
> URL: https://issues.apache.org/jira/browse/OAK-3437
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Reporter: Davide Giannella
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> When enabling OAK-1617 (still to be committed) there's a regression in the 
> {{oak-solr-core}} unit tests 
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR3}} 
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR4}} 
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5}} 
> The WIP of the feature can be found in 
> https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-1617 and a full 
> patch will be attached shortly for review in OAK-1617 itself.
> The feature is currently disabled, in order to enable it for unit testing an 
> approach like this can be taken 
> https://github.com/davidegiannella/jackrabbit-oak/blob/177df1a8073b1237857267e23d12a433e3d890a4/oak-core/src/test/java/org/apache/jackrabbit/oak/query/SQL2OptimiseQueryTest.java#L142
>  or setting the system property {{-Doak.query.sql2optimisation}}.



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

[jira] [Updated] (OAK-5776) Build failure: Cannot create directory : Filename too long

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5776:
--
Fix Version/s: 1.9.7

> Build failure: Cannot create directory : Filename too long
> --
>
> Key: OAK-5776
> URL: https://issues.apache.org/jira/browse/OAK-5776
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>  Labels: CI, build-failure, test-failure, windows
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/
> The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 
> 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #473 
> has failed.
> First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited 
> security) 64-bit Windows 
> only,nsfixtures=DOCUMENT_NS,profile=integrationTesting 
> #473|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/]
>  [console 
> log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/console]



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

[jira] [Updated] (OAK-7581) oak-examples: remove special case for failsafe plugin

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7581:
--
Fix Version/s: 1.9.7

> oak-examples: remove special case for failsafe plugin
> -
>
> Key: OAK-7581
> URL: https://issues.apache.org/jira/browse/OAK-7581
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: examples
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.6, 1.9.7
>
>




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

[jira] [Updated] (OAK-6914) Improve indexing progress estimates with multiple includes

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6914:
--
Fix Version/s: 1.9.7

> Improve indexing progress estimates with multiple includes
> --
>
> Key: OAK-6914
> URL: https://issues.apache.org/jira/browse/OAK-6914
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> With OAK-5970 support was added for providing ETA as indexing progresses. 
> However as discussed in the issue this estimate might not be good if indexes 
> have multiple include and excludes
> Purpose of this task is to look for ways to improve it



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

[jira] [Updated] (OAK-7224) oak-run check should have an option to check the segments checksums

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7224:
--
Fix Version/s: 1.9.7

> oak-run check should have an option to check the segments checksums
> ---
>
> Key: OAK-7224
> URL: https://issues.apache.org/jira/browse/OAK-7224
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>  Labels: tooling
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> {{oak-run check}} does currently *not* check the checksums of the segments. 
> As a consequence, there is no quick way of determining the state of the 
> repository (corrupt/valid), after corrupting some random node record, as we 
> currently do in {{CheckRepositoryTestBase#corruptRecord}}. To determine that, 
> there needs to be an attempt to read the corrupt record as part of a 
> traversal.
> An easier way would be to have a new dedicated option for this (i.e., 
> {{--segments}}) which checks by default the content of segments against the 
> checksums from all the tar files in the specified location. Additionally, it 
> could accept as an argument a list of tar files, the segments of which to be 
> checked.



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

[jira] [Updated] (OAK-7634) Repository migration docs should include info on TAR <-> Azure sidegrade

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7634:
--
Fix Version/s: 1.9.7

> Repository migration docs should include info on TAR <-> Azure sidegrade
> 
>
> Key: OAK-7634
> URL: https://issues.apache.org/jira/browse/OAK-7634
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.10, 1.9.6, 1.9.7
>
>




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

[jira] [Updated] (OAK-4524) LucenePropertyIndexTest#longRepExcerpt sometimes failing

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-4524:
--
Fix Version/s: 1.9.7

> LucenePropertyIndexTest#longRepExcerpt sometimes failing
> 
>
> Key: OAK-4524
> URL: https://issues.apache.org/jira/browse/OAK-4524
> Project: Jackrabbit Oak
>  Issue Type: Test
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> As reported by Julian on oak-dev@ it seems _longRepExcerpt_ is still failing 
> sometimes when query takes more than 10s e.g. see this [Jenkins 
> failure|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1000/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.lucene/LucenePropertyIndexTest/longRepExcerpt/].



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

[jira] [Updated] (OAK-6098) Build timeout

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6098:
--
Fix Version/s: 1.9.7

> Build timeout
> -
>
> Key: OAK-6098
> URL: https://issues.apache.org/jira/browse/OAK-6098
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #175 has failed.
> First failed run: [Jackrabbit Oak 
> #175|https://builds.apache.org/job/Jackrabbit%20Oak/175/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/175/console]
> This build timed out on node https://builds.apache.org/computer/H10. Usually 
> the build takes around 40mins. 
> {code}
> Build timed out (after 60 minutes). Marking the build as failed.
> {code}
> Also timed out on https://builds.apache.org/computer/cassandra5. See 
> https://builds.apache.org/view/J/job/Jackrabbit%20Oak/208/
> Also timed out on https://builds.apache.org/computer/ubuntu-eu2. See 
> https://builds.apache.org/job/Jackrabbit%20Oak/246/
> Also timed out on https://builds.apache.org/computer/ubuntu-2. See 
> https://builds.apache.org/job/Jackrabbit%20Oak/267/



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

[jira] [Updated] (OAK-7459) oak-run compact should support Azure Segment Store

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7459:
--
Fix Version/s: 1.9.7

> oak-run compact should support Azure Segment Store
> --
>
> Key: OAK-7459
> URL: https://issues.apache.org/jira/browse/OAK-7459
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: tooling
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> {{oak-run compact}} should accept Azure URIs for the segment store in order 
> to enable OffRC for Azure Segment Store.
> -Proposed options to add:-
>  * -{{azure-connection}}: connection URL to to connect to the Azure Storage-
>  * -{{azure-container}}: name of the container to use-
>  * -{{azure-root-path}}: segment store directory-
> The Azure URI will be taken as argument and will have the following format: 
> {{az:[https://myaccount.blob.core.windows.net/container/repo]}}, where *az* 
> identifies the cloud provider. The last missing piece is the secret key which 
> will be supplied as an environment variable, i.e. _AZURE_SECRET_KEY._



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

[jira] [Updated] (OAK-5792) TarMK: Implement tooling to repair broken nodes

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5792:
--
Fix Version/s: 1.9.7

> TarMK: Implement tooling to repair broken nodes
> ---
>
> Key: OAK-5792
> URL: https://issues.apache.org/jira/browse/OAK-5792
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: production, tooling
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> With {{oak-run check}} we can determine the last good revision of a 
> repository and use it to manually roll back a corrupted segment store. 
> Complementary to this we should implement a tool to roll forward a broken 
> revision to a fixed new revision. Such a tool needs to detect which items are 
> affected by a corruption and replace these items with markers. With this the 
> repository could brought back online and the markers could be used to 
> identify the locations in the tree where further manual action might be 
> needed. 



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

[jira] [Updated] (OAK-6264) Test failure: IllegalArgumentException during upgrade tests

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6264:
--
Fix Version/s: 1.9.7

> Test failure: IllegalArgumentException during upgrade tests 
> 
>
> Key: OAK-6264
> URL: https://issues.apache.org/jira/browse/OAK-6264
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #338 has failed.
> First failed run: [Jackrabbit Oak 
> #338|https://builds.apache.org/job/Jackrabbit%20Oak/338/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/338/console]
> {noformat}
> javax.jcr.RepositoryException: Failed to copy content
> Stacktrace
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy 
> content
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: javax.jcr.RepositoryException: Failed to copy content
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: java.lang.IllegalArgumentException
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> {noformat}
> This affects 
> {noformat}
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
>  the warning]
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
>  data store defined, checkpoints migrated]
> 
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment-tar -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to embedded, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to external, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to embedded, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}



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

[jira] [Updated] (OAK-6062) Test failure: CopyBinariesTest.validateMigration

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6062:
--
Fix Version/s: 1.9.7

> Test failure: CopyBinariesTest.validateMigration
> 
>
> Key: OAK-6062
> URL: https://issues.apache.org/jira/browse/OAK-6062
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
>  Labels: CI, flaky-test, jenkins, test-failure
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #146 has failed.
> First failed run: [Jackrabbit Oak 
> #146|https://builds.apache.org/job/Jackrabbit%20Oak/146/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/146/console]
> The test failure is:
> {noformat}
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest
> validateMigration[Copy references, no blobstores defined, document -> 
> segment-tar](org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest)  
> Time elapsed: 2.534 sec  <<< ERROR!
> javax.jcr.RepositoryException: Failed to copy content
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: java.lang.IllegalStateException: Branch with failed reset
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakOak0100: 
> Branch reset failed
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: 
> Empty branch cannot be reset
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> {noformat}



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

[jira] [Updated] (OAK-6957) Remove export for org.apache.jackrabbit.oak.security

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6957:
--
Fix Version/s: 1.9.7

> Remove export for org.apache.jackrabbit.oak.security
> 
>
> Key: OAK-6957
> URL: https://issues.apache.org/jira/browse/OAK-6957
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: core, security
>Reporter: angela
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> [~stillalex], with the fix you provided for the {{Jcr}} class we should be 
> able drop the export for _org.apache.jackrabbit.oak.security_
> Looking for remaining usages I noticed OAK-6956, which I will link to this 
> issue. 
> Apart from that, what's your take on this?



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

[jira] [Updated] (OAK-6513) Journal based Async Indexer

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6513:
--
Fix Version/s: 1.9.7

> Journal based Async Indexer
> ---
>
> Key: OAK-6513
> URL: https://issues.apache.org/jira/browse/OAK-6513
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> Current async indexer design is based on NodeState diff. This has served us 
> fine so far however off late it is not able to perform well if rate of 
> repository writes is high. When changes happen faster than index-update can 
> process them, larger and larger diffs will happen. These make index-updates 
> slower, which again lead to the next diff being ever larger than the one 
> before (assuming a constant ingestion rate). 
> In current diff based flow the indexer performs complete diff for all changes 
> happening between 2 cycle. It may happen that lots of writes happens but not 
> much indexable content is written. So doing diff there is a wasted effort.
> In 1.6 release for NRT Indexing we implemented a journal based indexing for 
> external changes(OAK-4808, OAK-5430). That approach can be generalized and 
> used for async indexing. 
> Before talking about the journal based approach lets see how IndexEditor work 
> currently
> h4. IndexEditor 
> Currently any IndexEditor performs 2 tasks
> # Identify which node is to be indexed based on some index definition. The 
> Editor gets invoked as part of content diff where it determines which 
> NodeState is to be indexed
> # Update the index based on node to be indexed
> For e.g. in oak-lucene we have LuceneIndexEditor which identifies the 
> NodeStates to be indexed and LuceneDocumentMaker which constructs the Lucene 
> Document from NodeState to be indexed. For journal based approach we can 
> decouple these 2 parts and thus have 
> * IndexEditor - Identifies which all paths need to be indexed for given index 
> definition
> * IndexUpdater - Updates the index based on given NodeState and its path
> h4. High Level Flow
> # Session Commit Flow
> ## Each index type would provide a IndexEditor which would be invoked as part 
> of commit (like sync indexes). These IndexEditor would just determine which 
> paths needs to be indexed. 
> ## As part of commit the paths to be indexed would be written to journal. 
> # AsyncIndexUpdate flow
> ## AsyncIndexUpdate would query this journal to fetch all such indexed paths 
> between the 2 checkpoints
> ## Based on the index path data it would invoke the {{IndexUpdater}} to 
> update the index for that path
> ## Merge the index updates
> h4. Benefits
> Such a design would have following impact
> # More work done as part of write
> # Marking of indexable content is distributed hence at indexing time lesser 
> work to be done
> # Indexing can progress in batches 
> # The indexers can be called in parallel
> h4. Journal Implementation
> DocumentNodeStore currently has an in built journal which is being used for 
> NRT Indexing. That feature can be exposed as an api. 
> For scaling index this design is mostly required for cluster case. So we can 
> possibly have both indexing support implemented and use the journal based 
> support for DocumentNodeStore setups. Or we can look into implementing such a 
> journal for SegmentNodeStore setups also
> h4. Open Points
> * Journal support in SegmentNodeStore
> * Handling deletes. 
> Detailed proposal - 
> https://wiki.apache.org/jackrabbit/Journal%20based%20Async%20Indexer



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

[jira] [Updated] (OAK-7639) Surface more DSGC operation stats

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7639:
--
Fix Version/s: (was: 1.9.6)

> Surface more DSGC operation stats 
> --
>
> Key: OAK-7639
> URL: https://issues.apache.org/jira/browse/OAK-7639
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob-plugins
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> The current metrics being pushed like should also be surfaced through the 
> MarkSweepGarbageCollector object :
> * Candidates found
> * Blobs deleted
> * Total approx. size deleted



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

[jira] [Updated] (OAK-7577) Update maven plugins from org.apache.maven.plugins

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7577:
--
Fix Version/s: (was: 1.9.6)

> Update maven plugins from org.apache.maven.plugins
> --
>
> Key: OAK-7577
> URL: https://issues.apache.org/jira/browse/OAK-7577
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: benchmarks, examples, parent, run, upgrade
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>
> ...to latest and greatest.



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

[jira] [Updated] (OAK-7358) Remove all usage of java.security.acl.Group for Java 12

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7358:
--
Fix Version/s: (was: 1.9.6)

> Remove all usage of java.security.acl.Group for Java 12
> ---
>
> Key: OAK-7358
> URL: https://issues.apache.org/jira/browse/OAK-7358
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> Followup of OAK-7024 for the actual removal of the Group class from the 
> codebase to be java 11 compliant.
> Not sure what to use for 'fix version', I went with 1.9.0 so this remains on 
> the radar, but we can push it out as needed.



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

[jira] [Updated] (OAK-5544) Improve indexing resilience

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5544:
--
Fix Version/s: (was: 1.9.6)

> Improve indexing resilience
> ---
>
> Key: OAK-5544
> URL: https://issues.apache.org/jira/browse/OAK-5544
> Project: Jackrabbit Oak
>  Issue Type: Epic
>  Components: lucene
>Reporter: Alexander Saar
>Assignee: Chetan Mehrotra
>Priority: Critical
>  Labels: resilience
> Fix For: 1.10, 1.9.7
>
>
> grouping the improvements for indexer resilience in this issue for easier 
> tracking



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

[jira] [Updated] (OAK-7224) oak-run check should have an option to check the segments checksums

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7224:
--
Fix Version/s: (was: 1.9.6)

> oak-run check should have an option to check the segments checksums
> ---
>
> Key: OAK-7224
> URL: https://issues.apache.org/jira/browse/OAK-7224
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>  Labels: tooling
> Fix For: 1.10, 1.9.7
>
>
> {{oak-run check}} does currently *not* check the checksums of the segments. 
> As a consequence, there is no quick way of determining the state of the 
> repository (corrupt/valid), after corrupting some random node record, as we 
> currently do in {{CheckRepositoryTestBase#corruptRecord}}. To determine that, 
> there needs to be an attempt to read the corrupt record as part of a 
> traversal.
> An easier way would be to have a new dedicated option for this (i.e., 
> {{--segments}}) which checks by default the content of segments against the 
> checksums from all the tar files in the specified location. Additionally, it 
> could accept as an argument a list of tar files, the segments of which to be 
> checked.



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

[jira] [Updated] (OAK-5776) Build failure: Cannot create directory : Filename too long

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5776:
--
Fix Version/s: (was: 1.9.6)

> Build failure: Cannot create directory : Filename too long
> --
>
> Key: OAK-5776
> URL: https://issues.apache.org/jira/browse/OAK-5776
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>  Labels: CI, build-failure, test-failure, windows
> Fix For: 1.10, 1.9.7
>
>
> Jenkins Windows CI failure: https://builds.apache.org/job/Oak-Win/
> The build Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited security) 
> 64-bit Windows only,nsfixtures=DOCUMENT_NS,profile=integrationTesting #473 
> has failed.
> First failed run: [Oak-Win/Windows slaves=Windows,jdk=JDK 1.7 (unlimited 
> security) 64-bit Windows 
> only,nsfixtures=DOCUMENT_NS,profile=integrationTesting 
> #473|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/]
>  [console 
> log|https://builds.apache.org/job/Oak-Win/Windows%20slaves=Windows,jdk=JDK%201.7%20(unlimited%20security)%2064-bit%20Windows%20only,nsfixtures=DOCUMENT_NS,profile=integrationTesting/473/console]



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

[jira] [Updated] (OAK-7459) oak-run compact should support Azure Segment Store

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7459:
--
Fix Version/s: (was: 1.9.6)

> oak-run compact should support Azure Segment Store
> --
>
> Key: OAK-7459
> URL: https://issues.apache.org/jira/browse/OAK-7459
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: tooling
> Fix For: 1.10, 1.9.7
>
>
> {{oak-run compact}} should accept Azure URIs for the segment store in order 
> to enable OffRC for Azure Segment Store.
> -Proposed options to add:-
>  * -{{azure-connection}}: connection URL to to connect to the Azure Storage-
>  * -{{azure-container}}: name of the container to use-
>  * -{{azure-root-path}}: segment store directory-
> The Azure URI will be taken as argument and will have the following format: 
> {{az:[https://myaccount.blob.core.windows.net/container/repo]}}, where *az* 
> identifies the cloud provider. The last missing piece is the secret key which 
> will be supplied as an environment variable, i.e. _AZURE_SECRET_KEY._



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

[jira] [Updated] (OAK-3809) Test failure: FacetTest

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-3809:
--
Fix Version/s: (was: 1.9.6)

> Test failure: FacetTest
> ---
>
> Key: OAK-3809
> URL: https://issues.apache.org/jira/browse/OAK-3809
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
> Environment: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: ci, jenkins, test, test-failure
> Fix For: 1.10, 1.9.7
>
>
> {{org.apache.jackrabbit.oak.jcr.query.FacetTest}} keeps failing on Jenkins:
> {noformat}
> testFacetRetrievalMV(org.apache.jackrabbit.oak.jcr.query.FacetTest)  Time 
> elapsed: 5.927 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected: (2), aem (1), apache (1), cosmetics (1), furniture (1)], tags:[repository 
> (2), software (2), aem (1), apache (1), cosmetics (1), furniture (1)], 
> tags:[repository (2), software (2), aem (1), apache (1), cosmetics (1), 
> furniture (1)], tags:[repository (2), software (2), aem (1), apache (1), 
> cosmetics (1), furniture (1)]]> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:100)
>   at junit.framework.Assert.assertEquals(Assert.java:107)
>   at junit.framework.TestCase.assertEquals(TestCase.java:269)
>   at 
> org.apache.jackrabbit.oak.jcr.query.FacetTest.testFacetRetrievalMV(FacetTest.java:80)
> {noformat}
> Failure seen at builds: 628, 629, 630, 633, 634, 636, 642, 643, 644, 645, 
> 648, 651, 656, 659, 660, 663, 666
> See e.g. 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/634/#showFailuresLink



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

[jira] [Updated] (OAK-7074) Ensure that all Documents are read with document order traversal indexing

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7074:
--
Fix Version/s: (was: 1.9.6)

> Ensure that all Documents are read with document order traversal indexing
> -
>
> Key: OAK-7074
> URL: https://issues.apache.org/jira/browse/OAK-7074
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> With OAK-6353 support was added for document order traversal indexing. In 
> this mode we open a DB cursor and try to read all documents from it using 
> document order traversal. Such a cursor may remain open for long time (2-4 
> hrs) and its possible that document may get reordered by the Mongo storage 
> engine. This would result in 2 aspects to be thought about 
> # Duplicate documents - Same document may appear more than once in result set 
> # Possibly missed document - It may be a possibility that a document got 
> moved and missed becoming part of cursor. 
> Both these aspects would need to be handled



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

[jira] [Updated] (OAK-5792) TarMK: Implement tooling to repair broken nodes

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5792:
--
Fix Version/s: (was: 1.9.6)

> TarMK: Implement tooling to repair broken nodes
> ---
>
> Key: OAK-5792
> URL: https://issues.apache.org/jira/browse/OAK-5792
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: production, tooling
> Fix For: 1.10, 1.9.7
>
>
> With {{oak-run check}} we can determine the last good revision of a 
> repository and use it to manually roll back a corrupted segment store. 
> Complementary to this we should implement a tool to roll forward a broken 
> revision to a fixed new revision. Such a tool needs to detect which items are 
> affected by a corruption and replace these items with markers. With this the 
> repository could brought back online and the markers could be used to 
> identify the locations in the tree where further manual action might be 
> needed. 



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

[jira] [Updated] (OAK-2155) TokenAuthenticationTest#tokenCreationWithPreAuth test failing repeatedly

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-2155:
--
Fix Version/s: (was: 1.9.6)

> TokenAuthenticationTest#tokenCreationWithPreAuth test failing repeatedly
> 
>
> Key: OAK-2155
> URL: https://issues.apache.org/jira/browse/OAK-2155
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, pojosr
>Reporter: Amit Jain
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: CI, test, ubuntu
> Fix For: 1.10, 1.9.7
>
>
> The test 
> {{org.apache.jackrabbit.oak.run.osgi.TokenAuthenticationTest#tokenCreationWithPreAuth}}
>  in oak-pojosr component failing repeatedly on the local system.
> Also, failing repeatedly on http://ci.apache.org/builders/oak-trunk-win7.



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

[jira] [Updated] (OAK-7581) oak-examples: remove special case for failsafe plugin

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7581:
--
Fix Version/s: (was: 1.9.6)

> oak-examples: remove special case for failsafe plugin
> -
>
> Key: OAK-7581
> URL: https://issues.apache.org/jira/browse/OAK-7581
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: examples
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>




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

[jira] [Updated] (OAK-6062) Test failure: CopyBinariesTest.validateMigration

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6062:
--
Fix Version/s: (was: 1.9.6)

> Test failure: CopyBinariesTest.validateMigration
> 
>
> Key: OAK-6062
> URL: https://issues.apache.org/jira/browse/OAK-6062
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
>  Labels: CI, flaky-test, jenkins, test-failure
> Fix For: 1.10, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #146 has failed.
> First failed run: [Jackrabbit Oak 
> #146|https://builds.apache.org/job/Jackrabbit%20Oak/146/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/146/console]
> The test failure is:
> {noformat}
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest
> validateMigration[Copy references, no blobstores defined, document -> 
> segment-tar](org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest)  
> Time elapsed: 2.534 sec  <<< ERROR!
> javax.jcr.RepositoryException: Failed to copy content
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: java.lang.IllegalStateException: Branch with failed reset
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakOak0100: 
> Branch reset failed
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> Caused by: org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: 
> Empty branch cannot be reset
>   at 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.prepare(CopyBinariesTest.java:183)
> {noformat}



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

[jira] [Updated] (OAK-6914) Improve indexing progress estimates with multiple includes

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6914:
--
Fix Version/s: (was: 1.9.6)

> Improve indexing progress estimates with multiple includes
> --
>
> Key: OAK-6914
> URL: https://issues.apache.org/jira/browse/OAK-6914
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.10, 1.9.7
>
>
> With OAK-5970 support was added for providing ETA as indexing progresses. 
> However as discussed in the issue this estimate might not be good if indexes 
> have multiple include and excludes
> Purpose of this task is to look for ways to improve it



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

[jira] [Updated] (OAK-6264) Test failure: IllegalArgumentException during upgrade tests

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6264:
--
Fix Version/s: (was: 1.9.6)

> Test failure: IllegalArgumentException during upgrade tests 
> 
>
> Key: OAK-6264
> URL: https://issues.apache.org/jira/browse/OAK-6264
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.10, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #338 has failed.
> First failed run: [Jackrabbit Oak 
> #338|https://builds.apache.org/job/Jackrabbit%20Oak/338/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/338/console]
> {noformat}
> javax.jcr.RepositoryException: Failed to copy content
> Stacktrace
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy 
> content
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: javax.jcr.RepositoryException: Failed to copy content
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: java.lang.IllegalArgumentException
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> {noformat}
> This affects 
> {noformat}
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
>  the warning]
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
>  data store defined, checkpoints migrated]
> 
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment-tar -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to embedded, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to external, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to embedded, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}



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

[jira] [Updated] (OAK-5544) Improve indexing resilience

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5544:
--
Fix Version/s: 1.9.7

> Improve indexing resilience
> ---
>
> Key: OAK-5544
> URL: https://issues.apache.org/jira/browse/OAK-5544
> Project: Jackrabbit Oak
>  Issue Type: Epic
>  Components: lucene
>Reporter: Alexander Saar
>Assignee: Chetan Mehrotra
>Priority: Critical
>  Labels: resilience
> Fix For: 1.10, 1.9.6, 1.9.7
>
>
> grouping the improvements for indexer resilience in this issue for easier 
> tracking



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

[jira] [Updated] (OAK-3355) Test failure: SpellcheckTest.testSpellcheckMultipleWords

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-3355:
--
Fix Version/s: (was: 1.9.6)

> Test failure: SpellcheckTest.testSpellcheckMultipleWords
> 
>
> Key: OAK-3355
> URL: https://issues.apache.org/jira/browse/OAK-3355
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Affects Versions: 1.0.24
> Environment: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: ci, jenkins, test, test-failure
> Fix For: 1.10, 1.9.7
>
>
> {{org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords}}
>  fails on Jenkins.
> Failure seen at builds: 389, 392, 395, 396, 562
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/396/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/console
> {noformat}
> testSpellcheckMultipleWords(org.apache.jackrabbit.oak.jcr.query.SpellcheckTest)
>   Time elapsed: 0.907 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[voting[ in] ontario]> but 
> was:<[voting[, voted,] ontario]>
>   at junit.framework.Assert.assertEquals(Assert.java:85)
>   at junit.framework.Assert.assertEquals(Assert.java:91)
>   at 
> org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords(SpellcheckTest.java:86)
> {noformat}



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

[jira] [Updated] (OAK-6166) Support versioning in the federated node store

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6166:
--
Fix Version/s: (was: 1.9.6)

> Support versioning in the federated node store
> --
>
> Key: OAK-6166
> URL: https://issues.apache.org/jira/browse/OAK-6166
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.10, 1.9.7
>
>
> The mount info provider should affect the versioning code as well, so version 
> histories for the mounted paths are stored separately. Similarly to what we 
> have in the indexing, let's store the mounted version histories under:
> /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME



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

[jira] [Updated] (OAK-7263) oak-lucene should not depend on oak-store-document

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7263:
--
Fix Version/s: (was: 1.9.6)

> oak-lucene should not depend on oak-store-document
> --
>
> Key: OAK-7263
> URL: https://issues.apache.org/jira/browse/OAK-7263
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> {{oak-lucene}} has a hard dependency on {{oak-store-document}} and that looks 
> wrong to me. 
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
> (default-compile) on project oak-lucene: Compilation failure: Compilation 
> failure: 
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[31,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[37,46]
>  cannot find symbol
> [ERROR]   symbol: class JournalProperty
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[33,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[34,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[38,47]
>  cannot find symbol
> [ERROR]   symbol: class JournalPropertyBuilder
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[106,12]
>  cannot find symbol
> [ERROR]   symbol:   class JournalProperty
> [ERROR]   location: class 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyBuilder
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java:[55,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[29,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[33,31]
>  cannot find symbol
> [ERROR]   symbol: class JournalProperty
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[22,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[23,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[25,54]
>  cannot find symbol
> [ERROR]   symbol: class JournalPropertyService
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[33,12]
>  cannot find symbol
> [ERROR]   symbol:   class JournalPropertyBuilder
> [ERROR]   location: class 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyService
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[50,5]
>  method does not override or implement a method from a supertype
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[61,5]
>  method does not override or implement a method from a supertype
> [ERROR] 
> 

[jira] [Updated] (OAK-6098) Build timeout

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6098:
--
Fix Version/s: (was: 1.9.6)

> Build timeout
> -
>
> Key: OAK-6098
> URL: https://issues.apache.org/jira/browse/OAK-6098
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.10, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #175 has failed.
> First failed run: [Jackrabbit Oak 
> #175|https://builds.apache.org/job/Jackrabbit%20Oak/175/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/175/console]
> This build timed out on node https://builds.apache.org/computer/H10. Usually 
> the build takes around 40mins. 
> {code}
> Build timed out (after 60 minutes). Marking the build as failed.
> {code}
> Also timed out on https://builds.apache.org/computer/cassandra5. See 
> https://builds.apache.org/view/J/job/Jackrabbit%20Oak/208/
> Also timed out on https://builds.apache.org/computer/ubuntu-eu2. See 
> https://builds.apache.org/job/Jackrabbit%20Oak/246/
> Also timed out on https://builds.apache.org/computer/ubuntu-2. See 
> https://builds.apache.org/job/Jackrabbit%20Oak/267/



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

[jira] [Updated] (OAK-6957) Remove export for org.apache.jackrabbit.oak.security

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6957:
--
Fix Version/s: (was: 1.9.6)

> Remove export for org.apache.jackrabbit.oak.security
> 
>
> Key: OAK-6957
> URL: https://issues.apache.org/jira/browse/OAK-6957
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: core, security
>Reporter: angela
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> [~stillalex], with the fix you provided for the {{Jcr}} class we should be 
> able drop the export for _org.apache.jackrabbit.oak.security_
> Looking for remaining usages I noticed OAK-6956, which I will link to this 
> issue. 
> Apart from that, what's your take on this?



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

[jira] [Updated] (OAK-7607) Update 7.0.* Tomcat dependencies once 7.0.90 is released

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7607:
--
Fix Version/s: (was: 1.9.6)

> Update 7.0.* Tomcat dependencies once 7.0.90 is released
> 
>
> Key: OAK-7607
> URL: https://issues.apache.org/jira/browse/OAK-7607
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent, webapp
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4, 
> candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.10, 1.9.7
>
>




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

[jira] [Updated] (OAK-7634) Repository migration docs should include info on TAR <-> Azure sidegrade

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-7634:
--
Fix Version/s: (was: 1.9.6)

> Repository migration docs should include info on TAR <-> Azure sidegrade
> 
>
> Key: OAK-7634
> URL: https://issues.apache.org/jira/browse/OAK-7634
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.10, 1.9.7
>
>




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

[jira] [Updated] (OAK-5923) Document S3 datastore

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-5923:
--
Fix Version/s: (was: 1.9.6)

> Document S3 datastore
> -
>
> Key: OAK-5923
> URL: https://issues.apache.org/jira/browse/OAK-5923
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: blob, doc
>Reporter: Alexander Klimetschek
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> The S3 datastore is currently hardly documented.
> The [generic blobstore 
> documentation|http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html] 
> is very much focused about the internal class structures, but quite confusing 
> for someone who wants to configure a specific datastore such as file and s3 
> (the only ones right now). S3 settings are not documented at all, the [config 
> page|http://jackrabbit.apache.org/oak/docs/osgi_config.html#config-blobstore] 
> only mentions the generic maxCachedBinarySize and cacheSizeInMB.
> The best bet is the [Adobe AEM product 
> documentation|https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html],
>  but that is for an older version and a few things changed since then.
> Specific items below. Some have been confusing people using oak-blob-cloud 
> 1.5.15:
> - "secret" property unclear (new)
> - secretKey & accessKey can be omitted to leverage IAM roles (new)
> - drop of proactiveCaching property (new)
> - aws bucket/region/etc. settings
> - config options (timeout, retries, threads)
> - understanding caching behavior and performance optimization
> - shared vs. non-shared options
> - migrating from a previous version, how to update the config
> - requirements on the AWS (account) side



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

[jira] [Updated] (OAK-6513) Journal based Async Indexer

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6513:
--
Fix Version/s: (was: 1.9.6)

> Journal based Async Indexer
> ---
>
> Key: OAK-6513
> URL: https://issues.apache.org/jira/browse/OAK-6513
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> Current async indexer design is based on NodeState diff. This has served us 
> fine so far however off late it is not able to perform well if rate of 
> repository writes is high. When changes happen faster than index-update can 
> process them, larger and larger diffs will happen. These make index-updates 
> slower, which again lead to the next diff being ever larger than the one 
> before (assuming a constant ingestion rate). 
> In current diff based flow the indexer performs complete diff for all changes 
> happening between 2 cycle. It may happen that lots of writes happens but not 
> much indexable content is written. So doing diff there is a wasted effort.
> In 1.6 release for NRT Indexing we implemented a journal based indexing for 
> external changes(OAK-4808, OAK-5430). That approach can be generalized and 
> used for async indexing. 
> Before talking about the journal based approach lets see how IndexEditor work 
> currently
> h4. IndexEditor 
> Currently any IndexEditor performs 2 tasks
> # Identify which node is to be indexed based on some index definition. The 
> Editor gets invoked as part of content diff where it determines which 
> NodeState is to be indexed
> # Update the index based on node to be indexed
> For e.g. in oak-lucene we have LuceneIndexEditor which identifies the 
> NodeStates to be indexed and LuceneDocumentMaker which constructs the Lucene 
> Document from NodeState to be indexed. For journal based approach we can 
> decouple these 2 parts and thus have 
> * IndexEditor - Identifies which all paths need to be indexed for given index 
> definition
> * IndexUpdater - Updates the index based on given NodeState and its path
> h4. High Level Flow
> # Session Commit Flow
> ## Each index type would provide a IndexEditor which would be invoked as part 
> of commit (like sync indexes). These IndexEditor would just determine which 
> paths needs to be indexed. 
> ## As part of commit the paths to be indexed would be written to journal. 
> # AsyncIndexUpdate flow
> ## AsyncIndexUpdate would query this journal to fetch all such indexed paths 
> between the 2 checkpoints
> ## Based on the index path data it would invoke the {{IndexUpdater}} to 
> update the index for that path
> ## Merge the index updates
> h4. Benefits
> Such a design would have following impact
> # More work done as part of write
> # Marking of indexable content is distributed hence at indexing time lesser 
> work to be done
> # Indexing can progress in batches 
> # The indexers can be called in parallel
> h4. Journal Implementation
> DocumentNodeStore currently has an in built journal which is being used for 
> NRT Indexing. That feature can be exposed as an api. 
> For scaling index this design is mostly required for cluster case. So we can 
> possibly have both indexing support implemented and use the journal based 
> support for DocumentNodeStore setups. Or we can look into implementing such a 
> journal for SegmentNodeStore setups also
> h4. Open Points
> * Journal support in SegmentNodeStore
> * Handling deletes. 
> Detailed proposal - 
> https://wiki.apache.org/jackrabbit/Journal%20based%20Async%20Indexer



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

[jira] [Updated] (OAK-4524) LucenePropertyIndexTest#longRepExcerpt sometimes failing

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-4524:
--
Fix Version/s: (was: 1.9.6)

> LucenePropertyIndexTest#longRepExcerpt sometimes failing
> 
>
> Key: OAK-4524
> URL: https://issues.apache.org/jira/browse/OAK-4524
> Project: Jackrabbit Oak
>  Issue Type: Test
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> As reported by Julian on oak-dev@ it seems _longRepExcerpt_ is still failing 
> sometimes when query takes more than 10s e.g. see this [Jenkins 
> failure|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1000/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.lucene/LucenePropertyIndexTest/longRepExcerpt/].



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

[jira] [Updated] (OAK-6069) Modularisation of Oak

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6069:
--
Fix Version/s: (was: 1.9.6)

> Modularisation of Oak
> -
>
> Key: OAK-6069
> URL: https://issues.apache.org/jira/browse/OAK-6069
> Project: Jackrabbit Oak
>  Issue Type: Epic
>  Components: core
>Reporter: angela
>Priority: Major
>  Labels: modularization
> Fix For: 1.10, 1.9.7
>
>
> Epic to track individual steps towards improved modularisation of Oak
> Until now Oak modules are all released together, which has some drawbacks. 
> Work on the modules must be somewhat kept in lockstep. Releasing a fix for a 
> module means all other modules must be in a state that can be released as 
> well. For a user it may be desirable to just update a single module to get a 
> fix and not a complete set of Oak bundles.
> The general approach for this epic should be to modularize only as needed and 
> not split everything. Obvious candidates are stable interfaces like Oak and 
> NodeStore API and NodeStore implementations.
> This requires fixing potential circular dependencies between logical modules 
> we want to split up. We need a better distinction between the interface part 
> of the SPI and its implementations. Utilities and commons code must be 
> reviewed and potentially moved.
> The oak-it related dependencies should be reconsidered and that a development 
> version of a NodeStore implementation can run integration tests. With the 
> current dependency setup a release of the NodeStore implementation is 
> required first to run the integration tests with those changes.
> Some modules will probably be moved to the top-level and have their own 
> branches and tags.
> To avoid branches it is important to always have trunk stable. Feature work 
> must happen on feature branches, in a forked module or protected with a 
> feature flag until it is ready for prime time. No more unstable work in trunk.
> Module owner is primarily responsible for module releases. At some point 
> there won't be a dedicated person anymore responsible for 'the Oak release'.



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

[jira] [Updated] (OAK-6288) Test failure: upgrade tests failing: Failed to copy content

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-6288:
--
Fix Version/s: (was: 1.9.6)

> Test failure: upgrade tests failing: Failed to copy content
> ---
>
> Key: OAK-6288
> URL: https://issues.apache.org/jira/browse/OAK-6288
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.10, 1.9.7
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #364 has failed.
> First failed run: [Jackrabbit Oak 
> #364|https://builds.apache.org/job/Jackrabbit%20Oak/364/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/364/console]
> Failing tests:
> {noformat}
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
>  the warning]
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
>  data store defined, checkpoints migrated]
> 
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment-tar -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to embedded, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to external, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to embedded, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}
> All seem to fail with
> {noformat}
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.737 
> s <<< FAILURE! - in 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest
> [ERROR] 
> validateMigration(org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest)
>   Time elapsed: 3.73 s  <<< ERROR!
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy 
> content
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> Caused by: java.lang.IllegalArgumentException
> {noformat}



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

[jira] [Updated] (OAK-3437) Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when enabling OAK-1617

[Davide Giannella (JIRA)]

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

Davide Giannella updated OAK-3437:
--
Fix Version/s: (was: 1.9.6)

> Regression in org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5 when 
> enabling OAK-1617
> --
>
> Key: OAK-3437
> URL: https://issues.apache.org/jira/browse/OAK-3437
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Reporter: Davide Giannella
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.10, 1.9.7
>
>
> When enabling OAK-1617 (still to be committed) there's a regression in the 
> {{oak-solr-core}} unit tests 
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR3}} 
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR4}} 
> - {{org.apache.jackrabbit.core.query.JoinTest#testJoinWithOR5}} 
> The WIP of the feature can be found in 
> https://github.com/davidegiannella/jackrabbit-oak/tree/OAK-1617 and a full 
> patch will be attached shortly for review in OAK-1617 itself.
> The feature is currently disabled, in order to enable it for unit testing an 
> approach like this can be taken 
> https://github.com/davidegiannella/jackrabbit-oak/blob/177df1a8073b1237857267e23d12a433e3d890a4/oak-core/src/test/java/org/apache/jackrabbit/oak/query/SQL2OptimiseQueryTest.java#L142
>  or setting the system property {{-Doak.query.sql2optimisation}}.



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

[jira] [Commented] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

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

Julian Reschke commented on OAK-7511:
-

Plan:
 * add jetbrains annotations dependency to parent pom
 * convert subprojects one at a time
 * remove JSR305 dependency from parent pom

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-7511.diff, convert-annotations.sh, 
> convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7511:

Fix Version/s: 1.10

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7511.diff, convert-annotations.sh, 
> convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency - use jetbrains nullability annotations instead

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7511:

Summary: get rid of JSR 305 dependency - use jetbrains nullability 
annotations instead  (was: get rid of JSR 305 dependency)

> get rid of JSR 305 dependency - use jetbrains nullability annotations instead
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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

[jira] [Updated] (OAK-7511) get rid of JSR 305 dependency

[Julian Reschke (JIRA)]

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

Julian Reschke updated OAK-7511:

Attachment: (was: convert-annotations.sh)

> get rid of JSR 305 dependency
> -
>
> Key: OAK-7511
> URL: https://issues.apache.org/jira/browse/OAK-7511
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7511.diff, convert-annotations.sh
>
>
> We should consider getting rid of the JSR 305 dependency (see 
> ).



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