[jira] [Updated] (OAK-8257) RDBDocumentStore: improve trace logging of batch operations
[ https://issues.apache.org/jira/browse/OAK-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8257: Priority: Minor (was: Major) > RDBDocumentStore: improve trace logging of batch operations > --- > > Key: OAK-8257 > URL: https://issues.apache.org/jira/browse/OAK-8257 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.14.0 > > Attachments: OAK-8257.diff > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8275) Add NIO channel access to JCR binaries
[ https://issues.apache.org/jira/browse/OAK-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8275: Summary: Add NIO channel access to JCR binaries (was: Add NIO channel access to JCR binaries.) > Add NIO channel access to JCR binaries > -- > > Key: OAK-8275 > URL: https://issues.apache.org/jira/browse/OAK-8275 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Henry Saginor >Priority: Major > > This is a follow up to the discussion started in OAK-8186. Currently JCR > binaries can only be accessed via InputStream. This is inefficient. It can > also be inadequate for some use cases. For example handling some Zip file > formats like deflate64 requires random access. > The proposal is to add API that returns SeekableByteChannel > Here is the new API I am proposing - > > [https://github.com/hsaginor/jackrabbit/blob/createChannel/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/ChannelBinary.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java] > (see 2 added methods) > And all of the implementation changes - > > [https://github.com/apache/jackrabbit-oak/compare/trunk...hsaginor:createChannel2] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8024) oak-http generates invalid html
[ https://issues.apache.org/jira/browse/OAK-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826119#comment-16826119 ] Julian Reschke edited comment on OAK-8024 at 4/26/19 4:18 AM: -- trunk: (1.12.0) [r1853083|http://svn.apache.org/r1853083] 1.10: [r1858172|http://svn.apache.org/r1858172] was (Author: reschke): trunk: (1.12.0) [r1853083|http://svn.apache.org/r1853083] > oak-http generates invalid html > > > Key: OAK-8024 > URL: https://issues.apache.org/jira/browse/OAK-8024 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-http >Reporter: Ruben Reusser >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: oak-http-fixes.patch > > > when using oak-http to explore a repository invalid html is rendered. The > title tag is rendered as causing the generated html to be invalid. > This is due to a depricated api usage in oak-http > please find attached a patch for this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8024) oak-http generates invalid html
[ https://issues.apache.org/jira/browse/OAK-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8024: Labels: candidate_oak_1_8 (was: candidate_oak_1_10) > oak-http generates invalid html > > > Key: OAK-8024 > URL: https://issues.apache.org/jira/browse/OAK-8024 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-http >Reporter: Ruben Reusser >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12.0, 1.10.3 > > Attachments: oak-http-fixes.patch > > > when using oak-http to explore a repository invalid html is rendered. The > title tag is rendered as causing the generated html to be invalid. > This is due to a depricated api usage in oak-http > please find attached a patch for this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8024) oak-http generates invalid html
[ https://issues.apache.org/jira/browse/OAK-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8024: Fix Version/s: 1.10.3 > oak-http generates invalid html > > > Key: OAK-8024 > URL: https://issues.apache.org/jira/browse/OAK-8024 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-http >Reporter: Ruben Reusser >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12.0, 1.10.3 > > Attachments: oak-http-fixes.patch > > > when using oak-http to explore a repository invalid html is rendered. The > title tag is rendered as causing the generated html to be invalid. > This is due to a depricated api usage in oak-http > please find attached a patch for this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7702) [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for uploads
[ https://issues.apache.org/jira/browse/OAK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826489#comment-16826489 ] Matt Ryan commented on OAK-7702: Some more basic info about the testing I did: * Blobs of different sizes were stored in an Azure blob storage container * Signed download URIs (both CDN and non-CDN) were created for each blob * Each signed URI was requested 50 times, and measurements for time to completion and throughput captured for each request * These tests were conducted from Azure and AWS virtual machines in eight different regions worldwide: ** US Northwest (where the blob storage was) ** US East ** Sao Paulo ** Ireland ** Paris ** Mumbai ** Sydney ** Tokyo > [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for > uploads > - > > Key: OAK-7702 > URL: https://issues.apache.org/jira/browse/OAK-7702 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Reporter: Alexander Klimetschek >Assignee: Matt Ryan >Priority: Major > > Azure Blob Store and S3 support CDNs in front of private containers/buckets, > which also work with presigned URLs ([S3 > docs|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html], > [cloudfront presigning > java|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CFPrivateDistJavaDevelopment.html], > [Azure > docs|https://docs.microsoft.com/en-us/azure/cdn/cdn-sas-storage-support]). > The binary access feature should support these for download URLs via a > configuration on the DataStore. > Currently, the S3 datastore has a config for [transfer > acceleration|https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html] > that if enabled, will make both upload & download URLs use the acceleration > option. However, this feature only makes sense for uploads, especially if CDN > is an option for downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7702) [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for uploads
[ https://issues.apache.org/jira/browse/OAK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826481#comment-16826481 ] Alexander Klimetschek commented on OAK-7702: S3 Transfer acceleration doesn’t cache and is not a CDN. > [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for > uploads > - > > Key: OAK-7702 > URL: https://issues.apache.org/jira/browse/OAK-7702 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Reporter: Alexander Klimetschek >Assignee: Matt Ryan >Priority: Major > > Azure Blob Store and S3 support CDNs in front of private containers/buckets, > which also work with presigned URLs ([S3 > docs|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html], > [cloudfront presigning > java|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CFPrivateDistJavaDevelopment.html], > [Azure > docs|https://docs.microsoft.com/en-us/azure/cdn/cdn-sas-storage-support]). > The binary access feature should support these for download URLs via a > configuration on the DataStore. > Currently, the S3 datastore has a config for [transfer > acceleration|https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html] > that if enabled, will make both upload & download URLs use the acceleration > option. However, this feature only makes sense for uploads, especially if CDN > is an option for downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8280) [Direct Binary Access] Allow client to veto use of CDN URI
[ https://issues.apache.org/jira/browse/OAK-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826477#comment-16826477 ] Matt Ryan commented on OAK-8280: The exception case is when the client requesting a URI is running on a VM for a cloud provider in the same region as where the blob storage is. This is true at least for Azure - if running on an Azure VM in the same region as the blob storage, the best performance for downloading a signed URI is to use a non-CDN URI in that particular case. In discussion with others on the Oak team, while we recognize that the testing results showed better performance, it is one edge case and may not be applicable in real-world scenarios. Most use cases are either web clients requesting the URIs (which could be anywhere but are almost certainly not running in a cloud VM), or external services which could also be running anywhere. An application built on top of the Oak repository would have no purpose in requesting the signed URI, because it is running in the same VM anyway and this doesn't improve the I/O usage of that application. So it would be hard for a client to know for sure that the specific binary it needs to request is in the same region and also be the case that the client has a reason to request a signed URI for that binary. Until we come up with a reasonable use case this is probably on hold. > [Direct Binary Access] Allow client to veto use of CDN URI > -- > > Key: OAK-8280 > URL: https://issues.apache.org/jira/browse/OAK-8280 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Reporter: Matt Ryan >Priority: Major > > As we learned in OAK-7702, using signed CDN URIs usually offers improved > throughput, but not always. Implementing this issue would mean that we > extend the API to allow a client to indicate that they do not want the CDN > URI, even if a CDN is configured, because the client somehow knows that the > non-CDN URI will be better. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8280) [Direct Binary Access] Allow client to veto use of CDN URI
[ https://issues.apache.org/jira/browse/OAK-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826473#comment-16826473 ] Matt Ryan commented on OAK-8280: See https://issues.apache.org/jira/browse/OAK-7702?focusedCommentId=16826464=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16826464. > [Direct Binary Access] Allow client to veto use of CDN URI > -- > > Key: OAK-8280 > URL: https://issues.apache.org/jira/browse/OAK-8280 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Reporter: Matt Ryan >Priority: Major > > As we learned in OAK-7702, using signed CDN URIs usually offers improved > throughput, but not always. Implementing this issue would mean that we > extend the API to allow a client to indicate that they do not want the CDN > URI, even if a CDN is configured, because the client somehow knows that the > non-CDN URI will be better. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8280) [Direct Binary Access] Allow client to veto use of CDN URI
Matt Ryan created OAK-8280: -- Summary: [Direct Binary Access] Allow client to veto use of CDN URI Key: OAK-8280 URL: https://issues.apache.org/jira/browse/OAK-8280 Project: Jackrabbit Oak Issue Type: Improvement Components: blob-cloud, blob-cloud-azure Reporter: Matt Ryan As we learned in OAK-7702, using signed CDN URIs usually offers improved throughput, but not always. Implementing this issue would mean that we extend the API to allow a client to indicate that they do not want the CDN URI, even if a CDN is configured, because the client somehow knows that the non-CDN URI will be better. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7702) [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for uploads
[ https://issues.apache.org/jira/browse/OAK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826472#comment-16826472 ] Matt Ryan commented on OAK-7702: FWIF, S3 transfer acceleration offers similar benefits to CloudFront (AWS's CDN) but with a different technology. Transfer acceleration allows you to resolve your request at a local node and use AWS's higher speed network to fulfill the request from the origin. There is no caching involved with transfer acceleration, so subsequent requests still are resolved at a local node but fulfilled from origin every time. CloudFront would follow a similar pattern for the first request, but the response would be cached at the local node so would be resolved and fulfilled at the local node in subsequent requests. [~alexander.klimetschek] it would be helpful to have some more context around your comment pertaining to S3 transfer acceleration where you asserted that "this feature only makes sense for uploads". Is that because uploads by definition are non-cacheable so CloudFront offers no additional advantage over transfer acceleration when it comes to uploads? If so I'd argue it may still be worthwhile to add support for uploading to S3 via CloudFront URIs, because this would mean a customer was not required to turn on transfer acceleration in addition to CloudFront to gain the upload speed improvement. > [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for > uploads > - > > Key: OAK-7702 > URL: https://issues.apache.org/jira/browse/OAK-7702 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Reporter: Alexander Klimetschek >Assignee: Matt Ryan >Priority: Major > > Azure Blob Store and S3 support CDNs in front of private containers/buckets, > which also work with presigned URLs ([S3 > docs|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html], > [cloudfront presigning > java|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CFPrivateDistJavaDevelopment.html], > [Azure > docs|https://docs.microsoft.com/en-us/azure/cdn/cdn-sas-storage-support]). > The binary access feature should support these for download URLs via a > configuration on the DataStore. > Currently, the S3 datastore has a config for [transfer > acceleration|https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html] > that if enabled, will make both upload & download URLs use the acceleration > option. However, this feature only makes sense for uploads, especially if CDN > is an option for downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7702) [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for uploads
[ https://issues.apache.org/jira/browse/OAK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826469#comment-16826469 ] Matt Ryan commented on OAK-7702: In a conversation with some others on the Oak team yesterday we went over the test results I had seen from Azure and how generally using the CDN URI - at least for downloads - offers equal if not better performance in most cases. I'm planning on moving forward with the implementation change in Oak to allow configuring a CDN domain, once this is better tested and verified to also work for S3. > [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for > uploads > - > > Key: OAK-7702 > URL: https://issues.apache.org/jira/browse/OAK-7702 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob-cloud, blob-cloud-azure >Reporter: Alexander Klimetschek >Assignee: Matt Ryan >Priority: Major > > Azure Blob Store and S3 support CDNs in front of private containers/buckets, > which also work with presigned URLs ([S3 > docs|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html], > [cloudfront presigning > java|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CFPrivateDistJavaDevelopment.html], > [Azure > docs|https://docs.microsoft.com/en-us/azure/cdn/cdn-sas-storage-support]). > The binary access feature should support these for download URLs via a > configuration on the DataStore. > Currently, the S3 datastore has a config for [transfer > acceleration|https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html] > that if enabled, will make both upload & download URLs use the acceleration > option. However, this feature only makes sense for uploads, especially if CDN > is an option for downloads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7702) [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for uploads
[
https://issues.apache.org/jira/browse/OAK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826464#comment-16826464
]
Matt Ryan commented on OAK-7702:
I did a quick POC using {{AzureDataStore}} which was fairly straightforward.
All that is required for Azure is for the user to create an Azure CDN connected
to their blob storage (e.g. via the Azure portal), then to use the new Azure
CDN domain name in the signed URI instead of the standard domain name.
In my testing, generally using the CDN URI gives equal or better performance as
compared to a standard URI. This appears to be true even for the initial
request, before the object has actually been put into the local CDN node cache.
One exception to this is if the machine requesting the URI is an Azure VM
running in the same Azure region as the Azure Blob Storage, in which case
requesting the standard URI offers better performance.
It is also possible to perform uploads via a signed CDN URI. I haven't had the
opportunity to conduct testing to compare this to standard uploads but hope to
do this soon.
I haven't done any experimentation with S3 yet - but again hope to be able to
do this soon.
> [Direct Binary Access] Add CDN support, use S3 Transfer Acceleration only for
> uploads
> -
>
> Key: OAK-7702
> URL: https://issues.apache.org/jira/browse/OAK-7702
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob-cloud, blob-cloud-azure
>Reporter: Alexander Klimetschek
>Assignee: Matt Ryan
>Priority: Major
>
> Azure Blob Store and S3 support CDNs in front of private containers/buckets,
> which also work with presigned URLs ([S3
> docs|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html],
> [cloudfront presigning
> java|https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CFPrivateDistJavaDevelopment.html],
> [Azure
> docs|https://docs.microsoft.com/en-us/azure/cdn/cdn-sas-storage-support]).
> The binary access feature should support these for download URLs via a
> configuration on the DataStore.
> Currently, the S3 datastore has a config for [transfer
> acceleration|https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html]
> that if enabled, will make both upload & download URLs use the acceleration
> option. However, this feature only makes sense for uploads, especially if CDN
> is an option for downloads.
--
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=16826463#comment-16826463 ] Henry Saginor commented on OAK-8186: [~mreutegg], [~mattvryan] To continue this conversation I opened a new ticket OAK-8275 specifically to focus on providing NIO channel access. Henry > 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: FileCopyTest3.java, OAK File Access.jpg, > fileCopyTest-0.0.1-SNAPSHOT.jar > > > 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 (v7.6.3#76005)
[jira] [Updated] (OAK-8275) Add NIO channel access to JCR binaries.
[ https://issues.apache.org/jira/browse/OAK-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Saginor updated OAK-8275: --- Description: This is a follow up to the discussion started in OAK-8186. Currently JCR binaries can only be accessed via InputStream. This is inefficient. It can also be inadequate for some use cases. For example handling some Zip file formats like deflate64 requires random access. The proposal is to add API that returns SeekableByteChannel Here is the new API I am proposing - [https://github.com/hsaginor/jackrabbit/blob/createChannel/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/ChannelBinary.java] [https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java] (see 2 added methods) And all of the implementation changes - [https://github.com/apache/jackrabbit-oak/compare/trunk...hsaginor:createChannel2] was: This is a follow up to the discussion started in OAK-8186. Currently JCR binaries can only be accessed via InputStream. This often is inefficient. The proposal is to add API that returns SeekableByteChannel Here is the new API I am proposing - [https://github.com/hsaginor/jackrabbit/blob/createChannel/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/ChannelBinary.java] [https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java] (see 2 added methods) And all of the implementation changes - [https://github.com/apache/jackrabbit-oak/compare/trunk...hsaginor:createChannel2] > Add NIO channel access to JCR binaries. > --- > > Key: OAK-8275 > URL: https://issues.apache.org/jira/browse/OAK-8275 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Henry Saginor >Priority: Major > > This is a follow up to the discussion started in OAK-8186. Currently JCR > binaries can only be accessed via InputStream. This is inefficient. It can > also be inadequate for some use cases. For example handling some Zip file > formats like deflate64 requires random access. > The proposal is to add API that returns SeekableByteChannel > Here is the new API I am proposing - > > [https://github.com/hsaginor/jackrabbit/blob/createChannel/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/ChannelBinary.java] > > [https://github.com/hsaginor/jackrabbit-oak/blob/createChannel2/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java] > (see 2 added methods) > And all of the implementation changes - > > [https://github.com/apache/jackrabbit-oak/compare/trunk...hsaginor:createChannel2] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8278) org.apache.jackrabbit.oak.plugins.document.rdb.RDBDataSourceFactory.CloseableDataSource doesn't implement java.sql.Wrapper correctly
[ https://issues.apache.org/jira/browse/OAK-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8278: Priority: Trivial (was: Minor) > org.apache.jackrabbit.oak.plugins.document.rdb.RDBDataSourceFactory.CloseableDataSource > doesn't implement java.sql.Wrapper correctly > - > > Key: OAK-8278 > URL: https://issues.apache.org/jira/browse/OAK-8278 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Trivial > Labels: candidate_oak_1_10 > > The class is supposed to wrap it's internal DataSource instance and should > implement the Wrapper interface accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OAK-8279) Build Jackrabbit Oak #2114 failed
[ https://issues.apache.org/jira/browse/OAK-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger closed OAK-8279. - > Build Jackrabbit Oak #2114 failed > - > > Key: OAK-8279 > URL: https://issues.apache.org/jira/browse/OAK-8279 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2114 has failed. > First failed run: [Jackrabbit Oak > #2114|https://builds.apache.org/job/Jackrabbit%20Oak/2114/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2114/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8279) Build Jackrabbit Oak #2114 failed
[ https://issues.apache.org/jira/browse/OAK-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-8279. --- Resolution: Duplicate > Build Jackrabbit Oak #2114 failed > - > > Key: OAK-8279 > URL: https://issues.apache.org/jira/browse/OAK-8279 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2114 has failed. > First failed run: [Jackrabbit Oak > #2114|https://builds.apache.org/job/Jackrabbit%20Oak/2114/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2114/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8279) Build Jackrabbit Oak #2114 failed
Hudson created OAK-8279: --- Summary: Build Jackrabbit Oak #2114 failed Key: OAK-8279 URL: https://issues.apache.org/jira/browse/OAK-8279 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2114 has failed. First failed run: [Jackrabbit Oak #2114|https://builds.apache.org/job/Jackrabbit%20Oak/2114/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2114/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8278) org.apache.jackrabbit.oak.plugins.document.rdb.RDBDataSourceFactory.CloseableDataSource doesn't implement java.sql.Wrapper correctly
Manfred Baedke created OAK-8278: --- Summary: org.apache.jackrabbit.oak.plugins.document.rdb.RDBDataSourceFactory.CloseableDataSource doesn't implement java.sql.Wrapper correctly Key: OAK-8278 URL: https://issues.apache.org/jira/browse/OAK-8278 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk Reporter: Manfred Baedke Assignee: Manfred Baedke The class is supposed to wrap it's internal DataSource instance and should implement the Wrapper interface accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8024) oak-http generates invalid html
[ https://issues.apache.org/jira/browse/OAK-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826119#comment-16826119 ] Julian Reschke commented on OAK-8024: - trunk: (1.12.0) [r1853083|http://svn.apache.org/r1853083] > oak-http generates invalid html > > > Key: OAK-8024 > URL: https://issues.apache.org/jira/browse/OAK-8024 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-http >Reporter: Ruben Reusser >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12.0 > > Attachments: oak-http-fixes.patch > > > when using oak-http to explore a repository invalid html is rendered. The > title tag is rendered as causing the generated html to be invalid. > This is due to a depricated api usage in oak-http > please find attached a patch for this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8024) oak-http generates invalid html
[ https://issues.apache.org/jira/browse/OAK-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8024: Labels: candidate_oak_1_10 (was: ) > oak-http generates invalid html > > > Key: OAK-8024 > URL: https://issues.apache.org/jira/browse/OAK-8024 > Project: Jackrabbit Oak > Issue Type: Bug > Components: oak-http >Reporter: Ruben Reusser >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12.0 > > Attachments: oak-http-fixes.patch > > > when using oak-http to explore a repository invalid html is rendered. The > title tag is rendered as causing the generated html to be invalid. > This is due to a depricated api usage in oak-http > please find attached a patch for this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774027#comment-16774027 ] Julian Reschke edited comment on OAK-8068 at 4/25/19 2:15 PM: -- trunk: (1.12.0) [r1854044|http://svn.apache.org/r1854044] 1.10: (1.10.1) [r1854116|http://svn.apache.org/r1854116] 1.8: (1.8.12) [r1854241|http://svn.apache.org/r1854241] 1.6: [r1858140|http://svn.apache.org/r1858140] was (Author: reschke): trunk: [r1854044|http://svn.apache.org/r1854044] 1.10: [r1854116|http://svn.apache.org/r1854116] 1.8: [r1854241|http://svn.apache.org/r1854241] > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.12.0, 1.10.1, 1.8.12, 1.6.18 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Fix Version/s: 1.6.18 > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_6 > Fix For: 1.12.0, 1.10.1, 1.8.12, 1.6.18 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Labels: candidate_oak_1_4 (was: candidate_oak_1_6) > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_4 > Fix For: 1.12.0, 1.10.1, 1.8.12, 1.6.18 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8273) RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
[
https://issues.apache.org/jira/browse/OAK-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826086#comment-16826086
]
Julian Reschke commented on OAK-8273:
-
trunk: [r1858139|http://svn.apache.org/r1858139]
> RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
>
>
> Key: OAK-8273
> URL: https://issues.apache.org/jira/browse/OAK-8273
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
> Attachments: OAK-8273.diff
>
>
> {{createOrUpdate()}} with 1 or 2 operations works, but is handled by the
> fallback code that is supposed to handle failures during bulk updates.
> Thus:
> - misleading DEBUG logging ("update conflict on...")
> - unnecessary cache invalidation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8273) RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
[
https://issues.apache.org/jira/browse/OAK-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8273:
Labels: candidate_oak_1_10 (was: )
> RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
>
>
> Key: OAK-8273
> URL: https://issues.apache.org/jira/browse/OAK-8273
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10
> Fix For: 1.14.0
>
> Attachments: OAK-8273.diff
>
>
> {{createOrUpdate()}} with 1 or 2 operations works, but is handled by the
> fallback code that is supposed to handle failures during bulk updates.
> Thus:
> - misleading DEBUG logging ("update conflict on...")
> - unnecessary cache invalidation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8273) RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
[
https://issues.apache.org/jira/browse/OAK-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-8273.
-
Resolution: Fixed
Fix Version/s: 1.14.0
> RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
>
>
> Key: OAK-8273
> URL: https://issues.apache.org/jira/browse/OAK-8273
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-8273.diff
>
>
> {{createOrUpdate()}} with 1 or 2 operations works, but is handled by the
> fallback code that is supposed to handle failures during bulk updates.
> Thus:
> - misleading DEBUG logging ("update conflict on...")
> - unnecessary cache invalidation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8277) Run tests on travis-ci.org on MongoDB 4.0.x
[ https://issues.apache.org/jira/browse/OAK-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-8277: -- Fix Version/s: 1.10.3 Merged into 1.10 branch: http://svn.apache.org/r1858125 > Run tests on travis-ci.org on MongoDB 4.0.x > --- > > Key: OAK-8277 > URL: https://issues.apache.org/jira/browse/OAK-8277 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.10.3, 1.14.0 > > > Tests currently use MongoDB 3.6.4 and should be updated to the most recent > stable version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8277) Run tests on travis-ci.org on MongoDB 4.0.x
[ https://issues.apache.org/jira/browse/OAK-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-8277. --- Resolution: Fixed Fix Version/s: 1.14.0 Update travis configuration in trunk to use MongoDB 4.0.9: http://svn.apache.org/r1858123 Updated documentation: http://svn.apache.org/r1858124 > Run tests on travis-ci.org on MongoDB 4.0.x > --- > > Key: OAK-8277 > URL: https://issues.apache.org/jira/browse/OAK-8277 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.14.0 > > > Tests currently use MongoDB 3.6.4 and should be updated to the most recent > stable version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8277) Run tests on travis-ci.org on MongoDB 4.0.x
Marcel Reutegger created OAK-8277: - Summary: Run tests on travis-ci.org on MongoDB 4.0.x Key: OAK-8277 URL: https://issues.apache.org/jira/browse/OAK-8277 Project: Jackrabbit Oak Issue Type: Task Components: mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Tests currently use MongoDB 3.6.4 and should be updated to the most recent stable version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-4318) Upgrade oak-solr to Solr 5.x
[ https://issues.apache.org/jira/browse/OAK-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826024#comment-16826024 ] Julian Reschke commented on OAK-4318: - trunk: (1.7.13) [r1818124|http://svn.apache.org/r1818124] [r1818042|http://svn.apache.org/r1818042] [r1817990|http://svn.apache.org/r1817990] [r1817988|http://svn.apache.org/r1817988] [r1817987|http://svn.apache.org/r1817987] [r1817919|http://svn.apache.org/r1817919] (1.7.12) [r1817091|http://svn.apache.org/r1817091] [r1817076|http://svn.apache.org/r1817076] [r1816834|http://svn.apache.org/r1816834] (1.7.12) [r1816721|http://svn.apache.org/r1816721] 1.6: (1.6.9) [r1823318|http://svn.apache.org/r1823318] [r1822884|http://svn.apache.org/r1822884] > Upgrade oak-solr to Solr 5.x > > > Key: OAK-4318 > URL: https://issues.apache.org/jira/browse/OAK-4318 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.7.14, 1.8.0, 1.6.9 > > Attachments: OAK-4318.1.patch, OAK-4318.patch > > > Since we support JDK 1.7+ we can upgrade Solr to 5.x versions (not 6.0 as it > requires java 8 though). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6646) Make it possible to set timeouts in Solr index connections
[ https://issues.apache.org/jira/browse/OAK-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826021#comment-16826021 ] Julian Reschke commented on OAK-6646: - [~teofili] - something weird es going on here. Apparently this was backported to 1.6 without setting fixVersion. > Make it possible to set timeouts in Solr index connections > -- > > Key: OAK-6646 > URL: https://issues.apache.org/jira/browse/OAK-6646 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.8.0 > > > Currently socket and connection timeouts for remote Solr clients are not > configurable. However in some environments, e.g. with proxies / load > balancers in front or having network latencies, it'd be useful to be able to > tweak such timeouts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6646) Make it possible to set timeouts in Solr index connections
[ https://issues.apache.org/jira/browse/OAK-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826019#comment-16826019 ] Julian Reschke commented on OAK-6646: - trunk: (1.7.8) [r1808034|http://svn.apache.org/r1808034] [r1808022|http://svn.apache.org/r1808022] 1.6: (1.6.9) [r1822884|http://svn.apache.org/r1822884] > Make it possible to set timeouts in Solr index connections > -- > > Key: OAK-6646 > URL: https://issues.apache.org/jira/browse/OAK-6646 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.8.0 > > > Currently socket and connection timeouts for remote Solr clients are not > configurable. However in some environments, e.g. with proxies / load > balancers in front or having network latencies, it'd be useful to be able to > tweak such timeouts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7178) RemoteSolrServerProvider should release connections on ping failures
[
https://issues.apache.org/jira/browse/OAK-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826014#comment-16826014
]
Julian Reschke commented on OAK-7178:
-
[~teofili] - something weird es going on here. Apparently this was backported
to 1.6 without setting fixVersion. It's also not clear whether it's in 1.8...
> RemoteSolrServerProvider should release connections on ping failures
>
>
> Key: OAK-7178
> URL: https://issues.apache.org/jira/browse/OAK-7178
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.8.0
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.9.0, 1.10.0
>
>
> Upon failures on {{SolrClient#ping}} connections to remote Solr(Cloud)
> instances should be released.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7178) RemoteSolrServerProvider should release connections on ping failures
[
https://issues.apache.org/jira/browse/OAK-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826011#comment-16826011
]
Julian Reschke commented on OAK-7178:
-
trunk: (1.9.0) [r1821495|http://svn.apache.org/r1821495]
1.8:
1.6: (1.6.9) [r1822884|http://svn.apache.org/r1822884]
> RemoteSolrServerProvider should release connections on ping failures
>
>
> Key: OAK-7178
> URL: https://issues.apache.org/jira/browse/OAK-7178
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Affects Versions: 1.8.0
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.9.0, 1.10.0
>
>
> Upon failures on {{SolrClient#ping}} connections to remote Solr(Cloud)
> instances should be released.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8273) RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
[
https://issues.apache.org/jira/browse/OAK-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8273:
Attachment: OAK-8273.diff
> RDBDocumentStore: createOrUpdate with less than 3 ops suboptimal
>
>
> Key: OAK-8273
> URL: https://issues.apache.org/jira/browse/OAK-8273
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8273.diff
>
>
> {{createOrUpdate()}} with 1 or 2 operations works, but is handled by the
> fallback code that is supposed to handle failures during bulk updates.
> Thus:
> - misleading DEBUG logging ("update conflict on...")
> - unnecessary cache invalidation
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825958#comment-16825958
]
Vikas Saurabh commented on OAK-8271:
Attaching [^OAK-8271.patch] which takes the mentioned approach for
non-fulltext conditions while retains the earlier approach for fulltext
conditions. It required to tweak an earlier test for property restriction
accordingly.
[~tmueller], as you expected, {{//}} type condition doesn't work but other
conditions that are utilizing wildcard do work out. I'm not sure where should
we document this though (I don't think we want to "support" {{//}} necessarily).
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-8271.patch
>
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8271) Lucene path transformed result doesn't accomodate wildcards in relative path
[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8271:
---
Attachment: OAK-8271.patch
> Lucene path transformed result doesn't accomodate wildcards in relative path
>
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-8271.patch
>
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
>+ foo
>- propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8274) Build Jackrabbit Oak #2110 failed
[ https://issues.apache.org/jira/browse/OAK-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825953#comment-16825953 ] Hudson commented on OAK-8274: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2113|https://builds.apache.org/job/Jackrabbit%20Oak/2113/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2113/console] > Build Jackrabbit Oak #2110 failed > - > > Key: OAK-8274 > URL: https://issues.apache.org/jira/browse/OAK-8274 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2110 has failed. > First failed run: [Jackrabbit Oak > #2110|https://builds.apache.org/job/Jackrabbit%20Oak/2110/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2110/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8276) OR-CompositeTreePermission.grantsPermission should loop over aggregates of supported permissions
[
https://issues.apache.org/jira/browse/OAK-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-8276.
-
Resolution: Fixed
Assignee: angela
Fix Version/s: 1.14.0
Committed revision 1858099.
> OR-CompositeTreePermission.grantsPermission should loop over aggregates of
> supported permissions
>
>
> Key: OAK-8276
> URL: https://issues.apache.org/jira/browse/OAK-8276
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.14.0
>
>
> [~stillalex], issue as discussed in person: while working on OAK-8269 and the
> missing tests for the ORing {{CompositeTreePermission}} i noticed the
> following issue in {{grantsPermission}}: after obtaining the supported
> permissions the code loops over the individual permissions aggregated. but
> passes the original permission instead of the supported ones which
> potentially only include a subset.
> the affected code inside the method looks as follows:
> {code}
> long supported = providers[i].supportedPermissions(tp, property,
> permissions);
> if (doEvaluate(supported)) {
> if (compositionType == AND) {
>[...]
> } else {
> for (long p : Permissions.aggregates(permissions)) {
> // < issue line 221
> [...]
> }
> }
> }
> {code}
> IMO the code at line 221 should rather be as follows:
> {code}
> for (long p : Permissions.aggregates(supported)) {
> {code}
> i will go ahead fix it along with a test case that illustrates the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8276) OR-CompositeTreePermission.grantsPermission should loop over aggregates of supported permissions
angela created OAK-8276:
---
Summary: OR-CompositeTreePermission.grantsPermission should loop
over aggregates of supported permissions
Key: OAK-8276
URL: https://issues.apache.org/jira/browse/OAK-8276
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: angela
[~stillalex], issue as discussed in person: while working on OAK-8269 and the
missing tests for the ORing {{CompositeTreePermission}} i noticed the following
issue in {{grantsPermission}}: after obtaining the supported permissions the
code loops over the individual permissions aggregated. but passes the original
permission instead of the supported ones which potentially only include a
subset.
the affected code inside the method looks as follows:
{code}
long supported = providers[i].supportedPermissions(tp, property,
permissions);
if (doEvaluate(supported)) {
if (compositionType == AND) {
[...]
} else {
for (long p : Permissions.aggregates(permissions)) {//
< issue line 221
[...]
}
}
}
{code}
IMO the code at line 221 should rather be as follows:
{code}
for (long p : Permissions.aggregates(supported)) {
{code}
i will go ahead fix it along with a test case that illustrates the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8249) NodeImpl#isNodeType could load mixin info lazily
[
https://issues.apache.org/jira/browse/OAK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825800#comment-16825800
]
Marcel Reutegger commented on OAK-8249:
---
bq. create a dedicated issue to not mix things too much
I understand, but then switching over to a correctly implemented
{{EffectiveNodeTypeProvider.isNodeType(Tree, String)}} would allow us to keep
the current EffectiveNodeTypeProvider interface as is.
On the changes you propose on GitHub. They look good to me. I was only
wondering about the new method on {{EffectiveNodeTypeProvider}} from a
compatibility perspective. Wouldn't it be better to have a default
implementation for the new method? But then, all implementations are probably
in Oak anyway and your proposal is less effort to migrate to.
> NodeImpl#isNodeType could load mixin info lazily
>
>
> Key: OAK-8249
> URL: https://issues.apache.org/jira/browse/OAK-8249
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, core-spi, jcr
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Minor
>
> The current isNodeType check loads both primary type and all mixins eagerly.
> I'm wondering how often is the case where someone only needs a primary type
> check, and if loading the mixins lazily would improve the throughput.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
