[jira] [Commented] (OAK-10314) Build Jackrabbit/jackrabbit-oak-trunk #1003 failed
[ https://issues.apache.org/jira/browse/OAK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737359#comment-17737359 ] Hudson commented on OAK-10314: -- Build is still failing. Failed run: [Jackrabbit/jackrabbit-oak-trunk #1016|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1016/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1016/console] > Build Jackrabbit/jackrabbit-oak-trunk #1003 failed > -- > > Key: OAK-10314 > URL: https://issues.apache.org/jira/browse/OAK-10314 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1003 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1003|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1003/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1003/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10093) Oak Blob Store support for SSE-C for AWS
[ https://issues.apache.org/jira/browse/OAK-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rishabh Daim resolved OAK-10093. Fix Version/s: 1.54.0 Resolution: Fixed > Oak Blob Store support for SSE-C for AWS > > > Key: OAK-10093 > URL: https://issues.apache.org/jira/browse/OAK-10093 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Rishabh Kumar >Assignee: Rishabh Daim >Priority: Major > Fix For: 1.54.0 > > > We need to provide the support for Customer Managed keys for Oak Blob Store > for AWS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10315. Fix Version/s: 1.54.0 Resolution: Fixed Merged the PR. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10329) oak-search-elastic: field values should be deduplicated
Fabrizio Fortino created OAK-10329: -- Summary: oak-search-elastic: field values should be deduplicated Key: OAK-10329 URL: https://issues.apache.org/jira/browse/OAK-10329 Project: Jackrabbit Oak Issue Type: Improvement Components: indexing Reporter: Fabrizio Fortino Assignee: Fabrizio Fortino -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10324) oak-search-elastic: IN queries on boolean fields should not fail when one of the value cannot be parsed
[ https://issues.apache.org/jira/browse/OAK-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Fortino resolved OAK-10324. Fix Version/s: 1.54.0 Resolution: Fixed > oak-search-elastic: IN queries on boolean fields should not fail when one of > the value cannot be parsed > --- > > Key: OAK-10324 > URL: https://issues.apache.org/jira/browse/OAK-10324 > Project: Jackrabbit Oak > Issue Type: Bug > Components: elastic-search >Reporter: Fabrizio Fortino >Assignee: Fabrizio Fortino >Priority: Major > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10328) jackrabbit-jcr-tests should have scope "tests"
Konrad Windszus created OAK-10328:
-
Summary: jackrabbit-jcr-tests should have scope "tests"
Key: OAK-10328
URL: https://issues.apache.org/jira/browse/OAK-10328
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.52.0
Reporter: Konrad Windszus
Currently the dependency {{jackrabbit-jcr-tests}} in {{oak-jcr}} have the
default scope ({{compile}}):
https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-jcr/pom.xml#L424.
In order to prevent that from being transitively inherited it should have
scope {{test}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10328) jackrabbit-jcr-tests should have scope "tests"
[
https://issues.apache.org/jira/browse/OAK-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10328:
-
Assignee: Konrad Windszus
> jackrabbit-jcr-tests should have scope "tests"
> --
>
> Key: OAK-10328
> URL: https://issues.apache.org/jira/browse/OAK-10328
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the dependency {{jackrabbit-jcr-tests}} in {{oak-jcr}} have the
> default scope ({{compile}}):
> https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-jcr/pom.xml#L424.
> In order to prevent that from being transitively inherited it should have
> scope {{test}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10327) Embedded dependencies should have "provided" scope
[
https://issues.apache.org/jira/browse/OAK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned OAK-10327:
-
Assignee: Konrad Windszus
> Embedded dependencies should have "provided" scope
> --
>
> Key: OAK-10327
> URL: https://issues.apache.org/jira/browse/OAK-10327
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.52.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The embedded dependencies in {{oak-segment-tar}} should have {{provided}}
> scope in order to prevent them from being transitively inherited:
> https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-segment-tar/pom.xml#L292
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10327) Embedded dependencies should have "provided" scope
Konrad Windszus created OAK-10327:
-
Summary: Embedded dependencies should have "provided" scope
Key: OAK-10327
URL: https://issues.apache.org/jira/browse/OAK-10327
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: 1.52.0
Reporter: Konrad Windszus
The embedded dependencies in {{oak-segment-tar}} should have {{provided}} scope
in order to prevent them from being transitively inherited:
https://github.com/apache/jackrabbit-oak/blob/05030fcba4275bfbf627b2c6786d05934cc9f791/oak-segment-tar/pom.xml#L292
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737070#comment-17737070
]
Manfred Baedke edited comment on OAK-10166 at 6/26/23 9:35 AM:
---
Actually, now I'm thinking that
??On the WebDAV wire, the lock token actually is a URI; so the behaviour of the
client might be ok.??
this is right. Is it not?
was (Author: baedke):
Actually, now I'm thinking that
??On the WebDAV wire, the lock token actually is a URI; so the behaviour of the
client might be ok.??
this is right. is it not?
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737070#comment-17737070
]
Manfred Baedke commented on OAK-10166:
--
Actually, now I'm thinking that
??On the WebDAV wire, the lock token actually is a URI; so the behaviour of the
client might be ok.??
this is right. is it not?
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737068#comment-17737068
]
Julian Reschke commented on OAK-10166:
--
Yes, if it rewrites the token that would be a bug. In which case we should open
a LibreOffice bug report.
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737057#comment-17737057
]
Manfred Baedke commented on OAK-10166:
--
[~reschke] I'll take a look. At first glace it seems to me that a client fails
to use a given lock token, which is plainly a bug, right?
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737054#comment-17737054
]
Julian Reschke edited comment on OAK-10166 at 6/26/23 9:05 AM:
---
[~baedke] - do you want to have a look? (I personally believe it's a client bug
that we may want to report...)
was (Author: reschke):
[~baedke] - do you want to have a look?
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-10166:
Assignee: Manfred Baedke (was: Julian Reschke)
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737054#comment-17737054
]
Julian Reschke commented on OAK-10166:
--
[~baedke] - do you want to have a look?
> Oak creates bogus lock token causing locking issue when editing a document by
> WebDAV with LibreOffice
> -
>
> Key: OAK-10166
> URL: https://issues.apache.org/jira/browse/OAK-10166
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Affects Versions: 1.48.0
>Reporter: Miguel Moquillon
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the
> JCR, the WebDAV access of office documents are provided with Jackrabbit
> {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here
> LibreOffice), a lock token is created and passed to the client. This lock
> token is generated by _JcrActiveLock_ which delegates the generation to
> _LockTokenMapper_ which, in the case of Oak, uses for doing
> {_}LockImpl#getLockToken(){_}. This method returns as token the path in the
> JCR of the node representing the file. Because the path contains the '/'
> separators, those are converted in "%2f". But, some office suite like
> LibreOffice seams to parse this token because they send back as token in the
> request header "Lock-Token" the token value in which the '/' character is
> encoded in "%2F" instead of "%2f" provoking consequently an error when
> unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a
> token value. At least, it should be encoded in Base64 or any other encoder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10311) Optimize SegmentBlob#equals for segment blobs that originate from the same blob store
[ https://issues.apache.org/jira/browse/OAK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737046#comment-17737046 ] Axel Hanikel commented on OAK-10311: It looks like doing what's in the description is not possible: there can be more than one blobId pointing to the same blob (esp when using direct binary upload), so different blobIds do not mean that the blobs are different. I'm still keeping the issue open for a bit, perhaps we get some other ideas for optimisation in the course of the discussion. > Optimize SegmentBlob#equals for segment blobs that originate from the same > blob store > - > > Key: OAK-10311 > URL: https://issues.apache.org/jira/browse/OAK-10311 > Project: Jackrabbit Oak > Issue Type: Story > Components: segment-tar >Affects Versions: 1.52.0 >Reporter: Axel Hanikel >Priority: Major > Fix For: 1.54.0 > > > [SegmentBlob#equals|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.52.0/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java] > can be optimized for blobs originating from the same external blob store: In > that case, SegmentBlob#getBlobId() can be used to determine if the blobs are > equal or not. That change should avoid falling back to a byte-by-byte > comparison if the two blobs have the same size, which can be very expensive > for larger blobs. > The optimization should be placed behind a code/feature toggle or system > property and disabled by default. The reason is that the contract of > [Blob#getContentIdentity|https://github.com/apache/jackrabbit-oak/blob/cc0521e1cf8dc10ad7a8d41a9f2d3fd2905e5c9b/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java#L80-L82] > does not mention the special case where Blobs reside in the same blob store. > As part of this story, integration and benchmark tests should be created to > demonstrate gains in performance and correct behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
