[jira] [Commented] (OAK-8198) Build Jackrabbit Oak #2066 failed
[ https://issues.apache.org/jira/browse/OAK-8198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811029#comment-16811029 ] Hudson commented on OAK-8198: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2068|https://builds.apache.org/job/Jackrabbit%20Oak/2068/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2068/console] > Build Jackrabbit Oak #2066 failed > - > > Key: OAK-8198 > URL: https://issues.apache.org/jira/browse/OAK-8198 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2066 has failed. > First failed run: [Jackrabbit Oak > #2066|https://builds.apache.org/job/Jackrabbit%20Oak/2066/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2066/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795135#comment-16795135 ] Julian Reschke edited comment on OAK-8111 at 4/5/19 3:36 PM: - trunk: [r1857010|http://svn.apache.org/r1857010] [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857013|http://svn.apache.org/r1857013] [r1857009|http://svn.apache.org/r1857009] 1.8: [r1857017|http://svn.apache.org/r1857017] was (Author: reschke): trunk: [r1857010|http://svn.apache.org/r1857010] [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857013|http://svn.apache.org/r1857013] [r1857009|http://svn.apache.org/r1857009] > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.12.0, 1.8.13, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8111: Fix Version/s: 1.8.13 > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.8.13, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8111: Labels: candidate_oak_1_6 (was: candidate_oak_1_8) > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.12.0, 1.8.13, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo
[ https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810943#comment-16810943 ] Julian Reschke commented on OAK-8146: - WIP: https://issues.apache.org/jira/secure/attachment/12965012/OAK-8146.diff > oak-run support for inspecting/modifying clusterNodeInfo > > > Key: OAK-8146 > URL: https://issues.apache.org/jira/browse/OAK-8146 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Attachments: OAK-8146.diff > > > - readable dump of cluster node info entries > - command to purge selected entries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8146) oak-run support for inspecting/modifying clusterNodeInfo
[ https://issues.apache.org/jira/browse/OAK-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8146: Attachment: OAK-8146.diff > oak-run support for inspecting/modifying clusterNodeInfo > > > Key: OAK-8146 > URL: https://issues.apache.org/jira/browse/OAK-8146 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: documentmk, run >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Attachments: OAK-8146.diff > > > - readable dump of cluster node info entries > - command to purge selected entries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.
[ https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810934#comment-16810934 ] Matt Ryan commented on OAK-8186: I had a discussion with [~hsagi...@gmail.com] offline yesterday to work through some of the questions. To summarize the discussion, what we determined is that the intent of this proposal is to allow *processing of a binary in a more efficient means* than streaming the binary through the JVM. We clarified the following points: * The proposal applies only to Oak instances using FileDataStore. * Oak will not provide direct access to any file. The proposal must only be about access to a copy of the file, created in a temporary location. * The access is effectively read-only, meaning that Oak will not directly apply any changes made to the file. If changes are made that the user wishes to apply, the changed binary must be applied as an update via existing JCR API. Again, the intent of the proposal is to allow the creation of the temporary file and third-party access to and processing of the file via more efficient means than streaming the binary through the JVM and the JCR APIs. See [this comment|https://issues.apache.org/jira/browse/OAK-8186?focusedCommentId=16808802=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16808802] for an example use. I've requested that more detailed testing of the proposal be done to figure out at what point making a file copy and working directly with the copied file is more efficient overall than using the existing supported approach. Having more data should help validate the justification (or not). Some open questions: * Who should be responsible to delete the temporary file after use? It seems to me the client should; the client knows when it is no longer needed. I don't want to burden Oak with the responsibility to delete the temporary files. * If we were to implement such a feature, would we limit it to FileDataStore or also support it for the cloud data stores? The same use case would apply either way. Clients could of course use the direct download URI for cloud data stores to make their own temp file, but in theory Oak could also provide a single API for creating the temp file and for cloud data stores use the direct download API to make the temp copy. ** Personally I'm less worried about how to do it for cloud data stores and more worried about whether we should do it at all. The cloud data stores with direct binary access have the effect of moving a lot of the binary state off of the Oak instance; creating a temp file seems a step backwards. Comments? /cc [~mduerig]/[~frm]/[~teofili] > Create API in OAK for file access to binaries in the repository. > > > Key: OAK-8186 > URL: https://issues.apache.org/jira/browse/OAK-8186 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Henry Saginor >Priority: Major > Attachments: OAK File Access.jpg > > > To get file access applications normally write binaries to temp files. It > would be nice if an API existed to get file access directly from OAK. This > might also meet some use cases documented at > [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase] > Suggested API and implementation can be found here [1]. Also, see attached > diagram [2]. > I can create a patch if I can get some feedback. Note that suggested API > makes it explicit that a temp file is created. I am not sure if direct access > to files in datasore would be safe. But I am open to suggestions. > [1] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java] > [2] > !OAK File Access.jpg! -- This message was sent by Atlassian JIRA
[jira] [Comment Edited] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795135#comment-16795135 ] Julian Reschke edited comment on OAK-8111 at 4/5/19 3:01 PM: - trunk: [r1857010|http://svn.apache.org/r1857010] [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857013|http://svn.apache.org/r1857013] [r1857009|http://svn.apache.org/r1857009] was (Author: reschke): trunk: [r1857010|http://svn.apache.org/r1857010] [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857009|http://svn.apache.org/r1857009] > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795135#comment-16795135 ] Julian Reschke edited comment on OAK-8111 at 4/5/19 2:47 PM: - trunk: [r1857010|http://svn.apache.org/r1857010] [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857009|http://svn.apache.org/r1857009] was (Author: reschke): trunk: [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857009|http://svn.apache.org/r1857009] > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8198) Build Jackrabbit Oak #2066 failed
[ https://issues.apache.org/jira/browse/OAK-8198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810885#comment-16810885 ] Hudson commented on OAK-8198: - Build is still failing. Failed run: [Jackrabbit Oak #2067|https://builds.apache.org/job/Jackrabbit%20Oak/2067/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2067/console] > Build Jackrabbit Oak #2066 failed > - > > Key: OAK-8198 > URL: https://issues.apache.org/jira/browse/OAK-8198 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2066 has failed. > First failed run: [Jackrabbit Oak > #2066|https://builds.apache.org/job/Jackrabbit%20Oak/2066/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2066/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8167) With uneven distribution of ACL restriction across facet labels statistical facet count become too inaccurate
[ https://issues.apache.org/jira/browse/OAK-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810862#comment-16810862 ] Vikas Saurabh edited comment on OAK-8167 at 4/5/19 2:06 PM: [~anchela], while I agree it can leak (not right away - but that's a bad arguement) information such that one can get an estimate of number of items that matched a query. But do note that by default we do "secure" facet evaluation - for obvious reason that's unscalable and not useful for any kind of practical facet implementation. Maybe we should document this as a warning that "statistical" facet evaluation can potentially leak information about number of items for a given query. How worrisome is that leakage though is beyond my abilities to assess. was (Author: catholicon): [~anchela], while I agree it can leak (not right away - but that's a bad arguement) information such that one can get an estimate of number of items that matched a query. But do note that by default we do "secure" facet evaluation - for obvious reason that's unscalable and useful for any kind of practical facet implementation. Maybe we should document this as a warning that "statistical" facet evaluation can potentially leak information about number of items for a given query. How worrisome is that leakage though is beyond my abilities to assess. > With uneven distribution of ACL restriction across facet labels statistical > facet count become too inaccurate > - > > Key: OAK-8167 > URL: https://issues.apache.org/jira/browse/OAK-8167 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query >Affects Versions: 1.6.16 >Reporter: Kelvin Xu >Priority: Major > Labels: vulnerability > > With the statistical mode, facet count is updated proportionally to the > percentage of accessible samples, which works for secured contents scattered > across different facets. For edge case where the whole facet (results) is not > accessible, the count still shows a number after the sampling percent is > applied. Even if the number is small, user experience is > misleading/inaccurate as nothing would return when the facet is clicked > (applied as a query condition). > For example, a ACLs/CUGs guarded "private" folder, in which all the assets > are tagged with the same facet value. Non authorized user may still see this > facet with a count but gets nothing when clicking on the facet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8167) With uneven distribution of ACL restriction across facet labels statistical facet count become too inaccurate
[ https://issues.apache.org/jira/browse/OAK-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810862#comment-16810862 ] Vikas Saurabh edited comment on OAK-8167 at 4/5/19 2:05 PM: [~anchela], while I agree it can leak (not right away - but that's a bad arguement) information such that one can get an estimate of number of items that matched a query. But do note that by default we do "secure" facet evaluation - for obvious reason that's unscalable and useful for any kind of practical facet implementation. Maybe we should document this as a warning that "statistical" facet evaluation can potentially leak information about number of items for a given query. How worrisome is that leakage though is beyond my abilities to assess. was (Author: catholicon): [~anchela], while I agree it can leak (not right away - but that's a bad arguement) information such that one can get an estimate of number of items in the repository. But do note that by default we do "secure" facet evaluation - for obvious reason that's unscalable and useful for any kind of practical facet implementation. Maybe we should document this as a warning that "statistical" facet evaluation can potentially leak information about number of items for a given query. How worrisome is that leakage though is beyond my abilities to assess. > With uneven distribution of ACL restriction across facet labels statistical > facet count become too inaccurate > - > > Key: OAK-8167 > URL: https://issues.apache.org/jira/browse/OAK-8167 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query >Affects Versions: 1.6.16 >Reporter: Kelvin Xu >Priority: Major > Labels: vulnerability > > With the statistical mode, facet count is updated proportionally to the > percentage of accessible samples, which works for secured contents scattered > across different facets. For edge case where the whole facet (results) is not > accessible, the count still shows a number after the sampling percent is > applied. Even if the number is small, user experience is > misleading/inaccurate as nothing would return when the facet is clicked > (applied as a query condition). > For example, a ACLs/CUGs guarded "private" folder, in which all the assets > are tagged with the same facet value. Non authorized user may still see this > facet with a count but gets nothing when clicking on the facet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8167) With uneven distribution of ACL restriction across facet labels statistical facet count become too inaccurate
[ https://issues.apache.org/jira/browse/OAK-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810862#comment-16810862 ] Vikas Saurabh commented on OAK-8167: [~anchela], while I agree it can leak (not right away - but that's a bad arguement) information such that one can get an estimate of number of items in the repository. But do note that by default we do "secure" facet evaluation - for obvious reason that's unscalable and useful for any kind of practical facet implementation. Maybe we should document this as a warning that "statistical" facet evaluation can potentially leak information about number of items for a given query. How worrisome is that leakage though is beyond my abilities to assess. > With uneven distribution of ACL restriction across facet labels statistical > facet count become too inaccurate > - > > Key: OAK-8167 > URL: https://issues.apache.org/jira/browse/OAK-8167 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query >Affects Versions: 1.6.16 >Reporter: Kelvin Xu >Priority: Major > Labels: vulnerability > > With the statistical mode, facet count is updated proportionally to the > percentage of accessible samples, which works for secured contents scattered > across different facets. For edge case where the whole facet (results) is not > accessible, the count still shows a number after the sampling percent is > applied. Even if the number is small, user experience is > misleading/inaccurate as nothing would return when the facet is clicked > (applied as a query condition). > For example, a ACLs/CUGs guarded "private" folder, in which all the assets > are tagged with the same facet value. Non authorized user may still see this > facet with a count but gets nothing when clicking on the facet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795135#comment-16795135 ] Julian Reschke edited comment on OAK-8111 at 4/5/19 2:02 PM: - trunk: [r1855776|http://svn.apache.org/r1855776] 1.10: [r1857009|http://svn.apache.org/r1857009] was (Author: reschke): trunk: [r1855776|http://svn.apache.org/r1855776] > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8111: Labels: candidate_oak_1_8 (was: candidate_oak_1_10 candidate_oak_1_8) > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8111: Fix Version/s: 1.10.3 > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8157) Download page gpg example needs second parameter
[
https://issues.apache.org/jira/browse/OAK-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810767#comment-16810767
]
Alex Deparvu commented on OAK-8157:
---
right, I was talking about the need to specify both files as mentioned on the
asf page [1] above:
bq. N.B. you must specify both the detached signature and the release file.
we don't seem to do it.
> Download page gpg example needs second parameter
>
>
> Key: OAK-8157
> URL: https://issues.apache.org/jira/browse/OAK-8157
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
>
> The download page [2] says:
> {quote}gpg --verify jackrabbit-X.Y.Z-src.zip.asc{quote}
> This should read:
> gpg --verify jackrabbit-X.Y.Z-src.zip.asc jackrabbit-X.Y.Z-src.zip
> It is important that the file being checked is also specified [1] on the
> command line.
> [1] [https://www.apache.org/info/verification.html#specify_both]
> [2] https://jackrabbit.apache.org/jcr/downloads.html#verify
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8198) Build Jackrabbit Oak #2066 failed
Hudson created OAK-8198: --- Summary: Build Jackrabbit Oak #2066 failed Key: OAK-8198 URL: https://issues.apache.org/jira/browse/OAK-8198 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2066 has failed. First failed run: [Jackrabbit Oak #2066|https://builds.apache.org/job/Jackrabbit%20Oak/2066/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2066/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo
[
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810738#comment-16810738
]
Julian Reschke commented on OAK-6880:
-
If people see the problem when their settings are as discussed, we should
*debug* this, not put a band-aid on it.
Oak doesn't have a direct restlet dependency, but oak-solr. And *that* declares
the dependency in it's parent pom.
> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve
> dependencies for project
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1,
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2
> was cached in the local repository, resolution will not be reattempted until
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo
[
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810731#comment-16810731
]
Christian Schneider commented on OAK-6880:
--
If some people see this problem and others don't.. wouldn't it still make sense
to apply the fix .. so it works for everyone?
> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve
> dependencies for project
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1,
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2
> was cached in the local repository, resolution will not be reattempted until
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6756) Convert oak-auth-external to OSGi R6 annotations
[ https://issues.apache.org/jira/browse/OAK-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810730#comment-16810730 ] Christian Schneider commented on OAK-6756: -- I also don`t have a good way to validate. > Convert oak-auth-external to OSGi R6 annotations > > > Key: OAK-6756 > URL: https://issues.apache.org/jira/browse/OAK-6756 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: auth-external >Reporter: Robert Munteanu >Assignee: angela >Priority: Major > Attachments: cschneider-OAK-6756.osgi-diff.txt > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo
[
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810728#comment-16810728
]
Julian Reschke commented on OAK-6880:
-
I definitively works with these settings. I use them all the time. Our build
machines do. [~baedke] confirmed yesterday.
> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve
> dependencies for project
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1,
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2
> was cached in the local repository, resolution will not be reattempted until
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8148) [Indexing] Implement sling metric to calculate number of slow queries(relative to all queries)
[ https://issues.apache.org/jira/browse/OAK-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810708#comment-16810708 ] Mohit Kataria edited comment on OAK-8148 at 4/5/19 11:23 AM: - PFA patch for this issue ([^0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch]). CC: [~tmueller], [~catholicon], [~teofili] was (Author: tihom88): PFA patch for this issue ([^0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch]). CC: [~tmueller], [~catholicon] > [Indexing] Implement sling metric to calculate number of slow > queries(relative to all queries) > --- > > Key: OAK-8148 > URL: https://issues.apache.org/jira/browse/OAK-8148 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing >Affects Versions: 1.10.2 >Reporter: Mohit Kataria >Priority: Major > Attachments: > 0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch > > > # We need a metric which calculates the number of slow queries compared to > all run queries. The value should be a percentile for slow queries relative > to all queries to prove 99% absence of slow product queries that traverse > more than 100'000 nodes) > # Add another metric showing total number of slow queries executed. > See: [https://sling.apache.org/documentation/bundles/metrics.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8148) [Indexing] Implement sling metric to calculate number of slow queries(relative to all queries)
[ https://issues.apache.org/jira/browse/OAK-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810708#comment-16810708 ] Mohit Kataria commented on OAK-8148: PFA patch for this issue ([^0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch]). CC: [~tmueller], [~catholicon] > [Indexing] Implement sling metric to calculate number of slow > queries(relative to all queries) > --- > > Key: OAK-8148 > URL: https://issues.apache.org/jira/browse/OAK-8148 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing >Affects Versions: 1.10.2 >Reporter: Mohit Kataria >Priority: Major > Attachments: > 0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch > > > # We need a metric which calculates the number of slow queries compared to > all run queries. The value should be a percentile for slow queries relative > to all queries to prove 99% absence of slow product queries that traverse > more than 100'000 nodes) > # Add another metric showing total number of slow queries executed. > See: [https://sling.apache.org/documentation/bundles/metrics.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8148) [Indexing] Implement sling metric to calculate number of slow queries(relative to all queries)
[ https://issues.apache.org/jira/browse/OAK-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8148: --- Attachment: 0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch > [Indexing] Implement sling metric to calculate number of slow > queries(relative to all queries) > --- > > Key: OAK-8148 > URL: https://issues.apache.org/jira/browse/OAK-8148 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing >Affects Versions: 1.10.2 >Reporter: Mohit Kataria >Priority: Major > Attachments: > 0001-OAK-8148-Indexing-Implement-sling-metric-to-calculat.patch > > > # We need a metric which calculates the number of slow queries compared to > all run queries. The value should be a percentile for slow queries relative > to all queries to prove 99% absence of slow product queries that traverse > more than 100'000 nodes) > # Add another metric showing total number of slow queries executed. > See: [https://sling.apache.org/documentation/bundles/metrics.html] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo
[
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810699#comment-16810699
]
Davide Giannella commented on OAK-6880:
---
[~reschke] It didn't work for me in the following condition
- empty m2 repo
- no settings.xml of any sort.
So for me the fix was needed in order to build oak.
> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve
> dependencies for project
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1,
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2
> was cached in the local repository, resolution will not be reattempted until
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8157) Download page gpg example needs second parameter
[
https://issues.apache.org/jira/browse/OAK-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810698#comment-16810698
]
Davide Giannella commented on OAK-8157:
---
we do some verification in the check-release as per following (at about L157)
{code:bash}
if [ ! -f "$BASEDIR/$RCDIR/$NAME.asc" ]; then
error " NOT FOUND: $NAME.asc"
elif gpg --verify "$BASEDIR/$RCDIR/$NAME.asc" 2>> "$LOGFILE" 1>&2; then
info " OK: $NAME.asc"
else
error " NOT OK: $NAME.asc"
fi
{code}
> Download page gpg example needs second parameter
>
>
> Key: OAK-8157
> URL: https://issues.apache.org/jira/browse/OAK-8157
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
>
> The download page [2] says:
> {quote}gpg --verify jackrabbit-X.Y.Z-src.zip.asc{quote}
> This should read:
> gpg --verify jackrabbit-X.Y.Z-src.zip.asc jackrabbit-X.Y.Z-src.zip
> It is important that the file being checked is also specified [1] on the
> command line.
> [1] [https://www.apache.org/info/verification.html#specify_both]
> [2] https://jackrabbit.apache.org/jcr/downloads.html#verify
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (OAK-8197) Update Oak 1.10 to Jackrabbit 2.18.1
[ https://issues.apache.org/jira/browse/OAK-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke moved JCR-4424 to OAK-8197: -- Component/s: (was: parent) parent Workflow: no-reopen-closed (was: no-reopen-closed, patch-avail) Key: OAK-8197 (was: JCR-4424) Project: Jackrabbit Oak (was: Jackrabbit Content Repository) > Update Oak 1.10 to Jackrabbit 2.18.1 > > > Key: OAK-8197 > URL: https://issues.apache.org/jira/browse/OAK-8197 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8196) Update httpclient/mime dependencies to 4.5.8
[ https://issues.apache.org/jira/browse/OAK-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810683#comment-16810683 ] Julian Reschke commented on OAK-8196: - trunk: [r1857000|http://svn.apache.org/r1857000] > Update httpclient/mime dependencies to 4.5.8 > > > Key: OAK-8196 > URL: https://issues.apache.org/jira/browse/OAK-8196 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8196) Update httpclient/mime dependencies to 4.5.8
[ https://issues.apache.org/jira/browse/OAK-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8196. - Resolution: Fixed > Update httpclient/mime dependencies to 4.5.8 > > > Key: OAK-8196 > URL: https://issues.apache.org/jira/browse/OAK-8196 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8196) Update httpclient/mime dependencies to 4.5.8
[ https://issues.apache.org/jira/browse/OAK-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8196: Labels: candidate_oak_1_10 (was: ) > Update httpclient/mime dependencies to 4.5.8 > > > Key: OAK-8196 > URL: https://issues.apache.org/jira/browse/OAK-8196 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8196) Update httpclient/mime dependencies to 4.5.8
Julian Reschke created OAK-8196: --- Summary: Update httpclient/mime dependencies to 4.5.8 Key: OAK-8196 URL: https://issues.apache.org/jira/browse/OAK-8196 Project: Jackrabbit Oak Issue Type: Task Components: parent Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.12.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
