[jira] [Commented] (OAK-4640) Provide a way for commit hook to record meta data for a given commit
[
https://issues.apache.org/jira/browse/OAK-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15408851#comment-15408851
]
Chetan Mehrotra commented on OAK-4640:
--
Thanks for highlighting that. That would make implementation bit tricky. Would
account for that
> Provide a way for commit hook to record meta data for a given commit
>
>
> Key: OAK-4640
> URL: https://issues.apache.org/jira/browse/OAK-4640
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Currently as part of commit the caller can provide a CommitInfo instance
> which captures some metadata related to commit being performed. Note that
> CommitInfo instance passed to NodeStore is immutable.
> For some usecases we need a way to add some more metadata to on going
> commit from within the CommitHook
> * OAK-4586 - Here we need to record nodetypes of nodes which got modified as
> part of current commit
> * OAK-4412 - Here we want to generate Documents for modified nodestate (per
> index definition) and "attach" it to current commit
> This meta information would later be used by Observer.
> To enable such cases some mutable state needs to be exposed as part of
> CommitInfo which can be used by CommitHooks.
> As per discussion of DL [1] this can be done by adding a new
> {{CommitAttributes}} instance which can be accessed from {{CommitInfo}}
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk%3DTMQ_q20dPSmdr7Q%3DcR8OfMDdJceDTd-pGs0pk_cK0g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4641) Using same index definition for both async and sync indexing
[
https://issues.apache.org/jira/browse/OAK-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4641:
-
Description:
Currently one can set "async" flag on an index definition to indicate wether
given index should be effective for synchronous commit or to be used for async
indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a way where
same index definition gets used in both.
As discussed on DL [1] for this to be done following changes need to be done
# Making {{async}} as a multi value property.
# Introducing a new IndexEditorProvider interface which can accept an
IndexingContext instance (OAK-4642). This provides access to
## indexing mode - sync or async
## index path of the index (see OAK-4152)
## CommitInfo (see OAK-4640)
[1]
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
was:
Currently one can set "async" flag on an index definition to indicate wether
given index should be effective for synchronous commit or to be used for async
indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a way where
same index definition gets used in both.
As discussed on DL [1] for this to be done following changes need to be done
# Making {{async}} as a multi value property.
# Introducing a new IndexEditorProvider interface which can accept an
IndexingContext instance. This provides access to
## indexing mode - sync or async
## index path of the index (see OAK-4152)
## CommitInfo (see OAK-4640)
[1]
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
> Using same index definition for both async and sync indexing
>
>
> Key: OAK-4641
> URL: https://issues.apache.org/jira/browse/OAK-4641
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.8
>
> Attachments: OAK-4641.patch
>
>
> Currently one can set "async" flag on an index definition to indicate wether
> given index should be effective for synchronous commit or to be used for
> async indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a
> way where same index definition gets used in both.
> As discussed on DL [1] for this to be done following changes need to be done
> # Making {{async}} as a multi value property.
> # Introducing a new IndexEditorProvider interface which can accept an
> IndexingContext instance (OAK-4642). This provides access to
> ## indexing mode - sync or async
> ## index path of the index (see OAK-4152)
> ## CommitInfo (see OAK-4640)
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4647) Multiplexing support in PropertyIndexStats MBean
[
https://issues.apache.org/jira/browse/OAK-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4647:
-
Priority: Minor (was: Major)
> Multiplexing support in PropertyIndexStats MBean
>
>
> Key: OAK-4647
> URL: https://issues.apache.org/jira/browse/OAK-4647
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.6
>
>
> {{PropertyIndexStats}} MBean added in OAK-4144 allows introspecting property
> index content. This needs to be adapted to support updated storage format
> when multiplexing is enabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4642:
-
Issue Type: Improvement (was: Technical task)
Parent: (was: OAK-4641)
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.8
>
> Attachments: OAK-4642-o4-v1.patch, OAK-4642-o4-v2.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-4642.
--
Resolution: Fixed
Fix Version/s: 1.5.8
Done with 1755243
*Usage*
Instead of just a normal callback now {{IndexUpdate}} would pass an instance of
type {{ContextAwareCallback}} to {{IndexEditorProvider}}. So an
{{IndexEditorProvider}} can cast the passed callback instance to
{{ContextAwareCallback}} and obtain the {{IndexingContext}} from that
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.8
>
> Attachments: OAK-4642-o4-v1.patch, OAK-4642-o4-v2.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4522: Attachment: OAK-4522.patch > Improve CommitRateLimiter to optionally block some commits > -- > > Key: OAK-4522 > URL: https://issues.apache.org/jira/browse/OAK-4522 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > Attachments: OAK-4522.patch > > > The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently > block them, and delays even those commits that are part of handling events. > Because of that, the queue can still get full, and possibly delaying commits > while handling events can make the situation even worse. > In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is > JCR-2746. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4522: Attachment: (was: OAK-4522.patch) > Improve CommitRateLimiter to optionally block some commits > -- > > Key: OAK-4522 > URL: https://issues.apache.org/jira/browse/OAK-4522 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > > The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently > block them, and delays even those commits that are part of handling events. > Because of that, the queue can still get full, and possibly delaying commits > while handling events can make the situation even worse. > In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is > JCR-2746. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4522) Improve CommitRateLimiter to optionally block some commits
[ https://issues.apache.org/jira/browse/OAK-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4522: Attachment: OAK-4522.patch OAK-4522.patch (work in progress) The BackgroundObserver.remove / removed is not yet correct, but other than that could you please review the patch [~egli]? > Improve CommitRateLimiter to optionally block some commits > -- > > Key: OAK-4522 > URL: https://issues.apache.org/jira/browse/OAK-4522 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: observation > Fix For: 1.6 > > > The CommitRateLimiter of OAK-1659 can delay commits, but doesn't currently > block them, and delays even those commits that are part of handling events. > Because of that, the queue can still get full, and possibly delaying commits > while handling events can make the situation even worse. > In Jackrabbit 2.x, we had a similar feature: JCR-2402. Also related is > JCR-2746. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407863#comment-15407863
]
Alex Parvulescu commented on OAK-4642:
--
+1 looks good. sorry about the overlapping changes from OAK-4641 :(
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch, OAK-4642-o4-v2.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4648) Improve documentation about structure of TAR files
[ https://issues.apache.org/jira/browse/OAK-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407826#comment-15407826 ] Francesco Mari commented on OAK-4648: - That's a very nice idea. I would wait a bit until oak-segment-tar reaches a more stable state, to avoid making these changes again and again. > Improve documentation about structure of TAR files > -- > > Key: OAK-4648 > URL: https://issues.apache.org/jira/browse/OAK-4648 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > > Improve the page at [1] to include a picture of the contents of a TAR file, > as done for segments in [2], to cover missing parts (e.g. binary references > files) and to better align it with latest oak-segment-tar improvements. > [1] http://jackrabbit.apache.org/oak/docs/nodestore/segment/tar.html > [2] http://jackrabbit.apache.org/oak/docs/nodestore/segment/records.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4301) Missing protection for system-maintained rep:externalId
[
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407812#comment-15407812
]
angela commented on OAK-4301:
-
Committed revision 1755191.
> Missing protection for system-maintained rep:externalId
>
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Critical
> Labels: security
> Fix For: 1.5.8
>
> Attachments: OAK-4301.patch
>
>
> while working on OAK-4101 i noticed that the current implementation doesn't
> provide any protection for the system maintained property {{rep:externalId}},
> which is intended to be an identifier for a given synchronized user/group
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API
> up to now i didn't manage to exploit the missing protection with the current
> default implementation but i found that minor (legitimate) changes have the
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation
> such that the rep:externalId really becomes system-maintained and prevent any
> unintentional or malicious modification outside of the scope of the
> sync-operations. furthermore uniqueness of this property should be asserted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4301) Missing protection for system-maintained rep:externalId
[
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4301.
-
Resolution: Fixed
> Missing protection for system-maintained rep:externalId
>
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Critical
> Labels: security
> Fix For: 1.5.8
>
> Attachments: OAK-4301.patch
>
>
> while working on OAK-4101 i noticed that the current implementation doesn't
> provide any protection for the system maintained property {{rep:externalId}},
> which is intended to be an identifier for a given synchronized user/group
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API
> up to now i didn't manage to exploit the missing protection with the current
> default implementation but i found that minor (legitimate) changes have the
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation
> such that the rep:externalId really becomes system-maintained and prevent any
> unintentional or malicious modification outside of the scope of the
> sync-operations. furthermore uniqueness of this property should be asserted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4648) Improve documentation about structure of TAR files
Andrei Dulceanu created OAK-4648: Summary: Improve documentation about structure of TAR files Key: OAK-4648 URL: https://issues.apache.org/jira/browse/OAK-4648 Project: Jackrabbit Oak Issue Type: Documentation Components: segment-tar Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu Priority: Minor Improve the page at [1] to include a picture of the contents of a TAR file, as done for segments in [2], to cover missing parts (e.g. binary references files) and to better align it with latest oak-segment-tar improvements. [1] http://jackrabbit.apache.org/oak/docs/nodestore/segment/tar.html [2] http://jackrabbit.apache.org/oak/docs/nodestore/segment/records.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4301) Missing protection for system-maintained rep:externalId
[
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406132#comment-15406132
]
angela edited comment on OAK-4301 at 8/4/16 1:42 PM:
-
Proposed patch including tests and documentation update.
[~tripod], maybe you want to take a closer look at this? the fix includes a
configuration option that turns on protection of rep:externalId by default. as
stated above using a dedicated mixin type was not feasible without major
rewrite of the whole module and i decided to just impose the protection using
the {{ExternalIdentityValidatorProvider}}.
With this enabled:
- writing {{rep:externalId}} is limited to the system session with 1 single
exception (i.e. adding and removing user/group + external id) to keep the
xml-import of external users working. [~tripod] if you have the impression that
this was not needed, we could prevent writing altogether.
- {{rep:externalId}} must be of type STRING and single valued
- {{rep:externalId}} must be unique
- the restrictions imposed by {{rep:externalPrincipalNames}} remains unchanged
The following actions are still possible with sufficient permissions:
- create external users
- remove external users
was (Author: anchela):
Proposed patch including tests and documentation update.
[~tripod], maybe you want to take a closer look at this? the fix includes a
configuration option that turns on protection of rep:externalId by default. as
stated above using a dedicated mixin type was not feasible without major
rewrite of the whole module and i decided to just impose the protection using
the {{ExternalIdentityValidatorProvider}}.
With this enabled:
- writing {{rep:externalId}} is limited to the system session with 1 single
exception (i.e. adding user/group + external id) to keep the xml-import of
external users working. [~tripod] if you have the impression that this was not
needed, we could prevent writing altogether.
- {{rep:externalId}} must be of type STRING and single valued
- {{rep:externalId}} must be unique
- the restrictions imposed by {{rep:externalPrincipalNames}} remains unchanged
The following actions are still possible with sufficient permissions:
- create external users
- remove external users
> Missing protection for system-maintained rep:externalId
>
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Critical
> Labels: security
> Fix For: 1.5.8
>
> Attachments: OAK-4301.patch
>
>
> while working on OAK-4101 i noticed that the current implementation doesn't
> provide any protection for the system maintained property {{rep:externalId}},
> which is intended to be an identifier for a given synchronized user/group
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API
> up to now i didn't manage to exploit the missing protection with the current
> default implementation but i found that minor (legitimate) changes have the
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation
> such that the rep:externalId really becomes system-maintained and prevent any
> unintentional or malicious modification outside of the scope of the
> sync-operations. furthermore uniqueness of this property should be asserted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4301) Missing protection for system-maintained rep:externalId
[
https://issues.apache.org/jira/browse/OAK-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406132#comment-15406132
]
angela edited comment on OAK-4301 at 8/4/16 1:42 PM:
-
Proposed patch including tests and documentation update.
[~tripod], maybe you want to take a closer look at this? the fix includes a
configuration option that turns on protection of rep:externalId by default. as
stated above using a dedicated mixin type was not feasible without major
rewrite of the whole module and i decided to just impose the protection using
the {{ExternalIdentityValidatorProvider}}.
With this enabled:
- writing {{rep:externalId}} is limited to the system session with 1 single
exception (i.e. adding user/group + external id) to keep the xml-import of
external users working. [~tripod] if you have the impression that this was not
needed, we could prevent writing altogether.
- {{rep:externalId}} must be of type STRING and single valued
- {{rep:externalId}} must be unique
- the restrictions imposed by {{rep:externalPrincipalNames}} remains unchanged
The following actions are still possible with sufficient permissions:
- create external users
- remove external users
was (Author: anchela):
Proposed patch including tests and documentation update.
[~tripod], maybe you want to take a closer look at this? the fix includes a
configuration option that turns on protection of rep:externalId by default. as
stated above using a dedicated mixin type was not feasible without major
rewrite of the whole module and i decided to just impose the protection using
the {{ExternalIdentityValidatorProvider}}.
With this enabled:
- writing {{rep:externalId}} is limited to the system session with 1 single
exception (i.e. adding user/group + external id) to keep the xml-import of
external users working. [~tripod] if you have the impression that this was not
needed, we could prevent writing altogether.
- {{rep:externalId}} must be of type STRING and single valued
- {{rep:externalId}} must be unique
- the restrictions imposed by {{rep:externalPrincipalNames}} remains unchanged
> Missing protection for system-maintained rep:externalId
>
>
> Key: OAK-4301
> URL: https://issues.apache.org/jira/browse/OAK-4301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Critical
> Labels: security
> Fix For: 1.5.8
>
> Attachments: OAK-4301.patch
>
>
> while working on OAK-4101 i noticed that the current implementation doesn't
> provide any protection for the system maintained property {{rep:externalId}},
> which is intended to be an identifier for a given synchronized user/group
> within an external IDP.
> in other words:
> - the system doesn't assert the uniqueness of a given external-id
> - the external-id properties can be changed using regular JCR API
> up to now i didn't manage to exploit the missing protection with the current
> default implementation but i found that minor (legitimate) changes have the
> potential to turn this into a critical vulnerability.
> therefore I would strongly recommend to change the default implementation
> such that the rep:externalId really becomes system-maintained and prevent any
> unintentional or malicious modification outside of the scope of the
> sync-operations. furthermore uniqueness of this property should be asserted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407595#comment-15407595
]
angela edited comment on OAK-4599 at 8/4/16 1:40 PM:
-
Fixed in trunk: r1755157
Fixed in 1.4: r1755172 (NOTE: due to improvements made with OAK-4365 the groovy
tests needed some refactoring)
Fixed in 1.2: r1755182 (NOTE: merging from trunk was not possible. had to
manually rebuild the fix; in particular the groovy test failed for unrelated
reasons when only adding the new tests).
NOTE: the state of the 1.0 branch is so much behind the recent development that
back-porting this issue including providing proper test coverage is not
feasible with reasonable effort. Since there restarting the affected
{{SecurityConfiguration}} components (in particular
{{AuthorizationConfiguration}} and {{UserConfiguration}}) helps working around
the issue, I decided not to fix it pro-actively in the 1.0 branch. Do so
requires backporting 2 years of development of the {{pojosr-module}}, which in
1.0 doesn't contain any groovy tests.
was (Author: anchela):
Fixed in trunk: r1755157
Fixed in 1.4: r1755172 (NOTE: due to improvements made with OAK-4365 the groovy
tests needed some refactoring)
Fixed in 1.2: r1755182 (NOTE: merging from trunk was not possible. had to
manually rebuild the fix; in particular the groovy test failed for unrelated
reasons when only adding the new tests).
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.4.6, 1.2.18, 1.5.8
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current
[jira] [Resolved] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-4599.
-
Resolution: Fixed
resolving issue in order to prevent fixed versions to be modified
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.4.6, 1.2.18, 1.5.8
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4599:
Fix Version/s: (was: 1.6)
1.5.8
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.4.6, 1.2.18, 1.5.8
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407595#comment-15407595
]
angela edited comment on OAK-4599 at 8/4/16 1:26 PM:
-
Fixed in trunk: r1755157
Fixed in 1.4: r1755172 (NOTE: due to improvements made with OAK-4365 the groovy
tests needed some refactoring)
Fixed in 1.2: r1755182 (NOTE: merging from trunk was not possible. had to
manually rebuild the fix; in particular the groovy test failed for unrelated
reasons when only adding the new tests).
was (Author: anchela):
Fixed in trunk: r1755157
Fixed in 1.4: r1755172 (NOTE: due to improvements made with OAK-4365 the groovy
tests needed some refactoring)
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.6, 1.4.6, 1.2.18
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was
[jira] [Closed] (OAK-4180) Use another NodeStore as a local cache for a remote Document store
[
https://issues.apache.org/jira/browse/OAK-4180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4180.
-
Bulk close for 1.5.7
> Use another NodeStore as a local cache for a remote Document store
> --
>
> Key: OAK-4180
> URL: https://issues.apache.org/jira/browse/OAK-4180
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: docs-impacting
> Fix For: 1.6, 1.5.7
>
> Attachments: OAK-4180-v1.patch
>
>
> DocumentNodeStore makes use of persistent cache to speed up its processing
> and save on making remote calls for data already present in cache
> In addition to that we can look into make use of Segment NodeStore as kind of
> "local copy" for certain paths in repository and route calls to it if
> possible. As part of this task I would like to prototype such an approach. At
> high level it would work as below
> # At start bootstrap the setup and shutdown it down
> # Use a modified "sidegrade" and copy over the NodeStats from Document store
> to Segment store. In such a copy we also store some Document specific
> properties like {{readRevision}} and {{lastRevision}} as hidden property in
> Segment NodeStates
> # In DocumentNodeStore we refactor the current code to extract a
> ## {{AbstractDocumentNodeState}} - Abase class which has some logic move out
> from {{DocumentNodeState}}
> ## {{SegmentDocumentNodeState}} extends above and delegate calls to a wrapped
> {{SegmentNodeState}}
> ## {{DocumentNodeState}} would also extend {{AbstractDocumentNodeState}} and
> hence delegate to some calls to parent. In this when a call comes for
> {{getChildNode}} it can check if that can be served by a local copy of
> {{SegmentNodeStore}} for given {{rootRevision}} then it delegates to that
> # For update plan is to make use of {{Observer}} which listens to changes and
> updates the local copy for certain configured paths.
> ## Key aspect to address here is handle the restart case where in a cluster a
> specific node restarts after some time then how it refreshes itself there
> *Usage*
> Following 2 OSGi configs would need to be seed
> * org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.config
> {noformat}
> secondary=B"true"
> {noformat}
> *
> org.apache.jackrabbit.oak.plugins.document.secondary.SecondaryStoreCacheService.config
> {noformat}
> includedPaths=[ \
> "/",
> ]
> {noformat}
> With these settings if DocumentNodeStoreService gets started it would pickup
> the cache and use it. Change {{includedPaths}} depending on paths in
> repository which you want to include in secondary store t
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3072) LuceneIndexEditorTest#copyOnWriteAndLocks failing on windows
[
https://issues.apache.org/jira/browse/OAK-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3072.
-
Bulk close for 1.5.7
> LuceneIndexEditorTest#copyOnWriteAndLocks failing on windows
>
>
> Key: OAK-3072
> URL: https://issues.apache.org/jira/browse/OAK-3072
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.3.1
> Environment: windows
>Reporter: Amit Jain
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.7
>
>
> LuceneIndexEditorTest#copyOnWriteAndLocks regularly fails on windows with the
> following exception
> {noformat}
> copyOnWriteAndLocks(org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
> Time elapsed: 0.19 sec <<< ERROR!
> org.apache.jackrabbit.oak.api.CommitFailedException: OakLucene0003: Failed to
> index the node /test
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.addOrUpdate(LuceneIndexEditor.java:297)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:191)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:74)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:63)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:130)
> at
> org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:396)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.copyOnWriteAndLocks(LuceneIndexEditorTest.java:376)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.io.IOException: Cannot overwrite:
>
[jira] [Closed] (OAK-3403) Multiplexing store support in Property indexes
[
https://issues.apache.org/jira/browse/OAK-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-3403.
-
Bulk close for 1.5.7
> Multiplexing store support in Property indexes
> --
>
> Key: OAK-3403
> URL: https://issues.apache.org/jira/browse/OAK-3403
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Fix For: 1.5.7
>
> Attachments: OAK-3403-v1.patch, OAK-3403-v2.patch, OAK-3403-v3.patch,
> OAK-3403-v4.patch, OAK-3403-v5.patch, OAK-3403-v6.patch
>
>
> In Oak one can define an index anywhere in the repository under a special
> node name {{oak:index}}. For e.g. if you want a property index for
> {{sling:resourceType}} at root level then you can create the index at
> /oak:index/resourceType and this index would store the index content at
> /oak:index/resourceType/:index.
> # Writing - At time of commit the IndexEditor would need to decide where the
> indexed content for a given path should be stored. To start with it can make
> use of PathToStoreMapper to decide which node to use the indexed content. For
> e.g. for /libs the indexed content is stored under :index-pr and for /content
> :index-sr is used. This is simpler for PropertyIndex where IndexStoreStrategy
> can be passed the right node
> # Reading - At time of reading the QueryIndex implementation would need to
> provide a union cursor which can perform lookup from all such store
> directories for a given index.
> *Open Items*
> # Supporting unique indexes
> # Introducing new oak:index - Node under oak:index node are special.
> Depending on parent path it might be possible that they would have to be
> created in both repositories. For e.g. /oak:index would have to be present in
> both PR and SR. While /content/foo/oak:index can live only in SR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4595) OSGiIT failure LuceneIndexProviderService exception
[
https://issues.apache.org/jira/browse/OAK-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4595.
-
Bulk close for 1.5.7
> OSGiIT failure LuceneIndexProviderService exception
> ---
>
> Key: OAK-4595
> URL: https://issues.apache.org/jira/browse/OAK-4595
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Alex Parvulescu
>Assignee: Chetan Mehrotra
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.7
>
>
> {{org.apache.jackrabbit.oak.osgi.OSGiIT}} is failing but not failing the
> build.
> {noformat}
> ERROR: org.apache.jackrabbit.oak-lucene (29):
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(44)]
> The activate method has thrown an exception
> java.lang.ExceptionInInitializerError
> at
> org.apache.lucene.codecs.lucene40.Lucene40Codec.(Lucene40Codec.java:52)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
> at org.apache.lucene.util.NamedSPILoader.(NamedSPILoader.java:45)
> at org.apache.lucene.util.NamedSPILoader.(NamedSPILoader.java:37)
> at org.apache.lucene.codecs.Codec.(Codec.java:41)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService.initializeClasses(LuceneIndexProviderService.java:452)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService.activate(LuceneIndexProviderService.java:230)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
> at
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
> at
> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
> at
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:313)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:127)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:868)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:835)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:827)
> at
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:907)
> at
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:871)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1477)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1398)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:1210)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:1148)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1429)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3423)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
> at
>
[jira] [Closed] (OAK-4622) SessionDelegate.lock speedup
[ https://issues.apache.org/jira/browse/OAK-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4622. - Bulk close for 1.5.7 > SessionDelegate.lock speedup > > > Key: OAK-4622 > URL: https://issues.apache.org/jira/browse/OAK-4622 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.7 > > > SessionDelegate.lock is called quite often and uses toString. This can be > done lazily only when needed, resulting in a small speedup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4599:
--
Fix Version/s: (was: 1.5.7)
1.6
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.6, 1.4.6, 1.2.18
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4616) Record suggestor status in suggest-data node
[
https://issues.apache.org/jira/browse/OAK-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4616.
-
Bulk close for 1.5.7
> Record suggestor status in suggest-data node
> -
>
> Key: OAK-4616
> URL: https://issues.apache.org/jira/browse/OAK-4616
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.7
>
> Attachments: OAK-4616-v1.patch
>
>
> Currently the suggestor storage logic maintains a timestamp of when suggestor
> data was last updated in property {{lastUpdated}} in {{:suggesterStatus}}
> node. Actual suggest data is stored in a separate node {{:suggest-data}}.
> {noformat}
> /oak:index/lucene-suggest: { reindexCount = 1, name = lucene-suggest,
> compatVersion = 2, reindex = false, type = lucene, jcr:primaryType =
> oak:QueryIndexDefinition, :facet-config = { ... }, indexRules = { ... },
> :data = { ... }, :status = { ... }, :suggest-data = { ... }, :suggesterStatus
> = { ... }}
> {noformat}
> It would be better if this property is stored in {{:suggest-data}}. This
> would simplify adding support for multiplexing as each dir node would be
> having complete info
> {noformat}
> + :oak:mount-foo-suggest-data
>- lastUpdated
> + :suggest-data
>- lastUpdated
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4588) Upgrade from JCR2 with S3DataStore doesn't work
[
https://issues.apache.org/jira/browse/OAK-4588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4588.
-
Bulk close for 1.5.7
> Upgrade from JCR2 with S3DataStore doesn't work
> ---
>
> Key: OAK-4588
> URL: https://issues.apache.org/jira/browse/OAK-4588
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Affects Versions: 1.4.5, 1.5.6
>Reporter: Tomek Rękawek
> Fix For: 1.6, 1.4.6, 1.5.7
>
>
> An attempt to upgrade JCR2 repository using S3DataStore fails:
> {noformat}
> 22.07.2016 12:31:36.839 [main] *ERROR*
> org.apache.jackrabbit.core.RepositoryImpl - failed to start Repository:
> Configured bean implementation class
> org.apache.jackrabbit.aws.ext.ds.S3DataStore was not found.
> org.apache.jackrabbit.core.config.ConfigurationException: Configured bean
> implementation class org.apache.jackrabbit.aws.ext.ds.S3DataStore was not
> found.
> at
> org.apache.jackrabbit.core.config.SimpleBeanFactory.newInstance(SimpleBeanFactory.java:44)
> ~[oak-upgrade.jar:1.4.2]
> at
> org.apache.jackrabbit.core.config.BeanConfig.newInstance(BeanConfig.java:191)
> ~[oak-upgrade.jar:1.4.2]
> at
> org.apache.jackrabbit.core.config.RepositoryConfigurationParser$4.getDataStore(RepositoryConfigurationParser.java:1032)
> ~[oak-upgrade.jar:1.4.2]
> at
> org.apache.jackrabbit.core.config.RepositoryConfig.getDataStore(RepositoryConfig.java:1072)
> ~[oak-upgrade.jar:1.4.2]
> at
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:281)
> ~[oak-upgrade.jar:1.4.2]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4624) Optionally ignore missing blobs during sidegrade
[
https://issues.apache.org/jira/browse/OAK-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-4624:
--
Fix Version/s: (was: 1.5.7)
> Optionally ignore missing blobs during sidegrade
>
>
> Key: OAK-4624
> URL: https://issues.apache.org/jira/browse/OAK-4624
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Reporter: Tomek Rękawek
> Fix For: 1.6, 1.4.6, 1.5.8
>
>
> For clients with corrupted data stores it'd be useful to finish sidegrade
> even if some of the blobs are missing from data stores. Add a new option
> {{--ignore-missing-binaries}} to proceed with the migration in such case. All
> missing binaries should be logged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-3758) Multiplexing store support in Reference index
[ https://issues.apache.org/jira/browse/OAK-3758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-3758. - Bulk close for 1.5.7 > Multiplexing store support in Reference index > - > > Key: OAK-3758 > URL: https://issues.apache.org/jira/browse/OAK-3758 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.5.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4633) Multiplexing store support for Node type indexes
[ https://issues.apache.org/jira/browse/OAK-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4633: -- Fix Version/s: (was: 1.5.7) 1.5.8 1.6 > Multiplexing store support for Node type indexes > > > Key: OAK-4633 > URL: https://issues.apache.org/jira/browse/OAK-4633 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: query >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 1.6, 1.5.8 > > > Support for PropertyIndexes was introduced as a part of OAK-3403, but was > incomplete, the query bits for the node type index are not properly wired > with the mount provider. Indexing looks fine, but the info is not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4592) Make DocumentNodeState immutable
[ https://issues.apache.org/jira/browse/OAK-4592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4592. - Bulk close for 1.5.7 > Make DocumentNodeState immutable > > > Key: OAK-4592 > URL: https://issues.apache.org/jira/browse/OAK-4592 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.6, 1.5.7 > > Attachments: OAK-4592-v1.patch > > > With OAK-4584 most of mutable operation on DocumentNodeState have been > removed. Only code (outside of test) which modify it is in > NodeDocument#getNodeAtRevision. This can be modified to create complete > DocumentNodeState in one go. > This would also simplify work in OAK-1312 and is overall a good change to do -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4593) Remove usage of DocumentMK in DocumentNodeStoreService
[ https://issues.apache.org/jira/browse/OAK-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4593. - Bulk close for 1.5.7 > Remove usage of DocumentMK in DocumentNodeStoreService > -- > > Key: OAK-4593 > URL: https://issues.apache.org/jira/browse/OAK-4593 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.7 > > > The DocumentNodeStoreService still uses the DocumentMK and should be > changed to only rely on the DocumentNodeStore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4344) LdapIdentityProvider always retrieves all attributes when looking up an LDAP entity.
[ https://issues.apache.org/jira/browse/OAK-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4344. - Bulk close for 1.5.7 > LdapIdentityProvider always retrieves all attributes when looking up an LDAP > entity. > > > Key: OAK-4344 > URL: https://issues.apache.org/jira/browse/OAK-4344 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Fix For: 1.6, 1.5.7 > > > Retrieving all attributes is usually unnecessary and may be costly. The > current behavior should be the default, but it should also be possible to > configure an explicit list of attributes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4613) Suggest directory should be opened in read only mode
[
https://issues.apache.org/jira/browse/OAK-4613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4613.
-
Bulk close for 1.5.7
> Suggest directory should be opened in read only mode
>
>
> Key: OAK-4613
> URL: https://issues.apache.org/jira/browse/OAK-4613
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.6, 1.5.7
>
>
> {{IndexNode}} currently opens the suggest directory in following way
> {code}
> if (definition.isSuggestEnabled()) {
> suggestDirectory = new OakDirectory(defnNodeState.builder(),
> ":suggest-data", definition, false);
> }
> {code}
> It has two issues
> * It open a builder on existing node state. Instead of that it should use
> {{ReadOnlyBuilder}}
> * The directory should be opened in read only mode
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4607) Add support for multiple directory in IndexCopier
[ https://issues.apache.org/jira/browse/OAK-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4607. - Bulk close for 1.5.7 > Add support for multiple directory in IndexCopier > - > > Key: OAK-4607 > URL: https://issues.apache.org/jira/browse/OAK-4607 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.6, 1.5.7 > > > As part of OAK-3629 IndexRootDirectory was introduced mange the local > directory per Oak Lucene Index. Internally it has support for handing > multiple Lucene Directory per Oak Lucene Index. > For multiplexing support (OAK-4566) and also hybrid lucene index this feature > needs to be exposed at IndexCopier level -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4470) Remove read revision method from DocumentNodeState
[
https://issues.apache.org/jira/browse/OAK-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella closed OAK-4470.
-
Bulk close for 1.5.7
> Remove read revision method from DocumentNodeState
> --
>
> Key: OAK-4470
> URL: https://issues.apache.org/jira/browse/OAK-4470
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.6, 1.5.7
>
> Attachments: OAK-4470.patch
>
>
> {{DocumentNodeState}} has a {{getRevision}} method which provides the read
> revision which was used at time of getting a {{DocumentNodeState}} out of
> {{NodeDocument}}. Looking at usage of this method indicates that its only
> used for root node and that usage can be replaced with call to
> {{getRootRevision}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OAK-4605) Separate persistent cache for diff and local_diff
[ https://issues.apache.org/jira/browse/OAK-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4605. - Bulk close for 1.5.7 > Separate persistent cache for diff and local_diff > - > > Key: OAK-4605 > URL: https://issues.apache.org/jira/browse/OAK-4605 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: observation > Fix For: 1.6, 1.5.7 > > Attachments: OAK-4605.patch > > > The DocumentNodeStore currently uses a single persistent cache for all types > (node, nodeChildren, diff, etc.). With this setup it is not possible to > assign a specific amount of disk space for some cache type(s). If there are > many inserts for one cache type, entries of another type may become > unavailable. In practice this can be a problem for the local_diff cache > entries that are important for efficient node state comparison. > Separating the diff and local_diff cache entries would also allow for > different configuration options like compression and different behaviour when > the async write back queue is full. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4500) Create tooling for reducing a document-based repository to a list of paths
[ https://issues.apache.org/jira/browse/OAK-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4500. - Bulk close for 1.5.7 > Create tooling for reducing a document-based repository to a list of paths > -- > > Key: OAK-4500 > URL: https://issues.apache.org/jira/browse/OAK-4500 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, upgrade >Reporter: Robert Munteanu >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.7 > > Attachments: OAK-4500-include-index.patch, OAK-4500-patchset.zip > > > When working with Document-based stores it is sometimes useful to be able to > reduce the repository to a certain subset for debugging purposes - it's > easier to ship out a reduced repository state. > Also, this would come in handy as tooling for preparing a repository mount in > the scope of multiplexing ( OAK-3401 ). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OAK-4594) Remove DocumentNodeState.copyTo()
[ https://issues.apache.org/jira/browse/OAK-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella closed OAK-4594. - Bulk close for 1.5.7 > Remove DocumentNodeState.copyTo() > - > > Key: OAK-4594 > URL: https://issues.apache.org/jira/browse/OAK-4594 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.6, 1.5.7 > > > The method is only used by DocumentMK and functionality should be moved > there. See also OAK-4584. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4585: -- Fix Version/s: (was: 1.5.7) 1.6 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6, 1.4.6 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407595#comment-15407595
]
angela commented on OAK-4599:
-
Fixed in trunk: r1755157
Fixed in 1.4: r1755172 (NOTE: due to improvements made with OAK-4365 the groovy
tests needed some refactoring)
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.4.6, 1.2.18, 1.5.7
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4599:
Fix Version/s: 1.2.18
1.4.6
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.4.6, 1.2.18, 1.5.7
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4641) Using same index definition for both async and sync indexing
[
https://issues.apache.org/jira/browse/OAK-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407565#comment-15407565
]
Chetan Mehrotra edited comment on OAK-4641 at 8/4/16 10:52 AM:
---
+1. Looks fine. Some coverage for multi value part would be good.
was (Author: chetanm):
+1. Looks fine
> Using same index definition for both async and sync indexing
>
>
> Key: OAK-4641
> URL: https://issues.apache.org/jira/browse/OAK-4641
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4641.patch
>
>
> Currently one can set "async" flag on an index definition to indicate wether
> given index should be effective for synchronous commit or to be used for
> async indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a
> way where same index definition gets used in both.
> As discussed on DL [1] for this to be done following changes need to be done
> # Making {{async}} as a multi value property.
> # Introducing a new IndexEditorProvider interface which can accept an
> IndexingContext instance. This provides access to
> ## indexing mode - sync or async
> ## index path of the index (see OAK-4152)
> ## CommitInfo (see OAK-4640)
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4641) Using same index definition for both async and sync indexing
[
https://issues.apache.org/jira/browse/OAK-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407565#comment-15407565
]
Chetan Mehrotra commented on OAK-4641:
--
+1. Looks fine
> Using same index definition for both async and sync indexing
>
>
> Key: OAK-4641
> URL: https://issues.apache.org/jira/browse/OAK-4641
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4641.patch
>
>
> Currently one can set "async" flag on an index definition to indicate wether
> given index should be effective for synchronous commit or to be used for
> async indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a
> way where same index definition gets used in both.
> As discussed on DL [1] for this to be done following changes need to be done
> # Making {{async}} as a multi value property.
> # Introducing a new IndexEditorProvider interface which can accept an
> IndexingContext instance. This provides access to
> ## indexing mode - sync or async
> ## index path of the index (see OAK-4152)
> ## CommitInfo (see OAK-4640)
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4642:
-
Attachment: OAK-4642-o4-v2.patch
[updated patch|^OAK-4642-o4-v2.patch] with testcase and final implementation
[~alex.parvulescu] Please review!
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch, OAK-4642-o4-v2.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4641) Using same index definition for both async and sync indexing
[
https://issues.apache.org/jira/browse/OAK-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4641:
-
Attachment: OAK-4641.patch
proposed patch. [~chetanm] please review!
> Using same index definition for both async and sync indexing
>
>
> Key: OAK-4641
> URL: https://issues.apache.org/jira/browse/OAK-4641
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4641.patch
>
>
> Currently one can set "async" flag on an index definition to indicate wether
> given index should be effective for synchronous commit or to be used for
> async indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a
> way where same index definition gets used in both.
> As discussed on DL [1] for this to be done following changes need to be done
> # Making {{async}} as a multi value property.
> # Introducing a new IndexEditorProvider interface which can accept an
> IndexingContext instance. This provides access to
> ## indexing mode - sync or async
> ## index path of the index (see OAK-4152)
> ## CommitInfo (see OAK-4640)
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4647) Multiplexing support in PropertyIndexStats MBean
Chetan Mehrotra created OAK-4647:
Summary: Multiplexing support in PropertyIndexStats MBean
Key: OAK-4647
URL: https://issues.apache.org/jira/browse/OAK-4647
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Chetan Mehrotra
Assignee: Alex Parvulescu
Fix For: 1.6
{{PropertyIndexStats}} MBean added in OAK-4144 allows introspecting property
index content. This needs to be adapted to support updated storage format when
multiplexing is enabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407508#comment-15407508
]
Alex Parvulescu commented on OAK-4642:
--
ah, even better yes! so you have all the pieces needed to add to the
{{IndexingContext}}. just making sure you're not blocked on OAK-4614 for this.
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407500#comment-15407500
]
Chetan Mehrotra commented on OAK-4642:
--
Should not it be determined from {{async}} property of {{IndexUpdate}}? The one
in definition would become a multi value going forward
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-4566) Multiplexing store support in Lucene Indexes
[
https://issues.apache.org/jira/browse/OAK-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-4566.
--
Resolution: Fixed
Fix Version/s: 1.5.8
Changes merged to trunk from branch. Opened issue for pending task OAK-4643,
OAK-4644.
Resolving this as fixed
> Multiplexing store support in Lucene Indexes
>
>
> Key: OAK-4566
> URL: https://issues.apache.org/jira/browse/OAK-4566
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6, 1.5.8
>
>
> Similar to OAK-3403 we need support multiplexing store in Lucene indexes.
> This can be done by having multiple directories under given index definition.
> For e.g. currently the Lucene indexes for an index /oak:index/assetIndex are
> stored in node /oak:index/assetIndex/:dir. For supporting multiple indexes
> which get stored in different stores we can have structure like
> {noformat}
> /oak:index/assetIndex
> + :oak:mount1-dir
> + :dir
> {noformat}
> In above structure index content for paths which are part of mount1 would be
> store in Lucene files stores under {{:oak:mount1-dir}} while the rest go in
> default location {{:dir}
> # *Writing* - At the time of indexing the {{LuceneIndexEditor}} should pick
> up correct writer i.e. one which is mapped to right directory node in
> repository
> # *Reading* - For reading we would have one {{IndexSearcher}} per directory
> node and then query would be executed against both and a joined cursor would
> be made
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407498#comment-15407498
]
Alex Parvulescu commented on OAK-4642:
--
I think you already have access to the {{indexing mode}} here. If
{{definition.getString(ASYNC_PROPERTY_NAME)}} is null then it's a sync job.
OAK-4614 will extend this definition, but all the required bits are already in
place for this patch.
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4646) How can i remove a registered custom privilege
[
https://issues.apache.org/jira/browse/OAK-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Piovesana updated OAK-4646:
-
Description:
I did register a custom privilege:
{code}
PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
session.getWorkspace()).getPrivilegeManager();
Privilege privilege =
privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new
String[0]);
{code}
How can i delete it? There's an automated way to specify all my custom
privileges (like the file _*.config_ for the custom node types)?
was:
I did register a custom privilege:
{code}
PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
session.getWorkspace()).getPrivilegeManager();
Privilege privilege =
privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new
String[0]);
{code}
How can i delete it? There's an automated way to specify all my custom
privileges(like the file _*.config_ for the custom node types)?
> How can i remove a registered custom privilege
> --
>
> Key: OAK-4646
> URL: https://issues.apache.org/jira/browse/OAK-4646
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core
>Affects Versions: 1.4.5
>Reporter: Marco Piovesana
>
> I did register a custom privilege:
> {code}
> PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
> session.getWorkspace()).getPrivilegeManager();
> Privilege privilege =
> privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new
> String[0]);
> {code}
> How can i delete it? There's an automated way to specify all my custom
> privileges (like the file _*.config_ for the custom node types)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4646) How can i remove a registered custom privilege
Marco Piovesana created OAK-4646:
Summary: How can i remove a registered custom privilege
Key: OAK-4646
URL: https://issues.apache.org/jira/browse/OAK-4646
Project: Jackrabbit Oak
Issue Type: Wish
Components: core
Affects Versions: 1.4.5
Reporter: Marco Piovesana
I did register a custom privilege:
{code}
PrivilegeManager privilegeManager = ((JackrabbitWorkspace)
session.getWorkspace()).getPrivilegeManager();
Privilege privilege =
privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new
String[0]);
{code}
How can i delete it? There's an automated way to specify all my custom
privileges(like the file _*.config_ for the custom node types)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4645) Enable read-only constraint for unique property index updates
[
https://issues.apache.org/jira/browse/OAK-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407491#comment-15407491
]
Alex Parvulescu commented on OAK-4645:
--
I dropped the constraint with http://svn.apache.org/viewvc?rev=1755159=rev
/fyi [~chetanm]
> Enable read-only constraint for unique property index updates
> -
>
> Key: OAK-4645
> URL: https://issues.apache.org/jira/browse/OAK-4645
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: query
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>
> I'll disable the read-only constraint for now to make testing the
> multiplexing bits easier.
> This issue is to track setting the default back to {{true}} once the work has
> stabilized.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4645) Enable read-only constraint for unique property index updates
Alex Parvulescu created OAK-4645:
Summary: Enable read-only constraint for unique property index
updates
Key: OAK-4645
URL: https://issues.apache.org/jira/browse/OAK-4645
Project: Jackrabbit Oak
Issue Type: Technical task
Components: query
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
I'll disable the read-only constraint for now to make testing the
multiplexing bits easier.
This issue is to track setting the default back to {{true}} once the work has
stabilized.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4644) Support multiple readers in LuceneIndexMBean
Chetan Mehrotra created OAK-4644: Summary: Support multiple readers in LuceneIndexMBean Key: OAK-4644 URL: https://issues.apache.org/jira/browse/OAK-4644 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 1.6 With OAK-4566 its possible to have multiple readers and thus multiple directory for a singe index. LuceneIndexMBean should be adapted to support this kind of setup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4643) Support multiple readers in suggester, spellcheck and faceted search
Chetan Mehrotra created OAK-4643: Summary: Support multiple readers in suggester, spellcheck and faceted search Key: OAK-4643 URL: https://issues.apache.org/jira/browse/OAK-4643 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene Reporter: Chetan Mehrotra Fix For: 1.6 As part of OAK-4566 normal search has been modified to support multiple readers. However for suggester, spellcheck and faceted search the logic is still working with the assumption of single reader. Those parts need to be adapted to support multiple readers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4599:
Fix Version/s: 1.5.7
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Fix For: 1.5.7
>
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
> the {{SecurityConfiguration}} by the new ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4599) SecurityProviderRegistration fails to update config param of SecurityConfiguration(s)
[
https://issues.apache.org/jira/browse/OAK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407440#comment-15407440
]
angela edited comment on OAK-4599 at 8/4/16 9:07 AM:
-
[~chetanm], that was the missing piece! confirming that this indeed shows the
issue. to be really sure I added and ran a variant that changes the
{{AuthorizableActionProvider}} config _before_ disabling the unary
configuration. Thanks so much for looking into this, very much appreciated.
was (Author: anchela):
[~chetanm], that was the missing piece! confirming that this indeed shows the
issue. to be really sure I added also run a variant the changes the
{{AuthorizableActionProvider}} config _before_ disabling the unary
configuration. Thanks so much for looking into this, very much appreciated.
> SecurityProviderRegistration fails to update config param of
> SecurityConfiguration(s)
> -
>
> Key: OAK-4599
> URL: https://issues.apache.org/jira/browse/OAK-4599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.8, 1.2.16, 1.0.32, 1.4.5, 1.5.6
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4599-v3.patch, OAK-4599_test_1_2.patch,
> OAK-4599_test_trunk.patch, OAK-4599_trunk_var2.patch
>
>
> h4. Steps to reproduce
> - start Oak repository in OSGi setup with additional required (custom)
> services that are passed to various security modules as config parameter such
> as e.g. {{RestrictionProvider}}, {{UserAuthenticationFactory}},
> {{AuthorizableNodeName}} or {{AuthorizableActionProvider}}
> - verify that the security setup contains the custom configurations
> - now, force a re-registration of the {{SecurityProvider}} by changing a
> referenced/required security service, which is not associated with the custom
> configuration as specified in the initial setup
> - once completed any {{SecurityConfiguration}}, that is associated with
> custom configuration params such as the examples listed above will no longer
> have the corresponding params set.
> h4. Finding step by step
> - {{SecurityProviderRegistration}} waits until all configured required
> service references have been registered and all non-dynamic references have
> been resolved.
> - Once everything is resolved the {{SecurityProviderRegistration}} looks as
> expected including all configuration parameters
> - {{SecurityProviderRegistration}} now starts creating a new
> {{SecurityProvider}} instance with all the unary and required module
> references.
> - During this step it also calls {{initializeConfiguration}} in order to have
> the modules populated with additional stuff from the
> {{SecurityProviderRegistration}} and it's here we have IMHO a bug: The
> {{initializeConfiguration}} will push the params from
> {{SecurityProviderRegistration}} to the {{SecurityConfiguration}}, while at
> the same time trying to merge params defined directly on the
> {{SecurityConfiguration}}.
> h4. Explanation
> In a plain Java setup as it was initial designed for the
> {{SecurityProviderImpl}}: The 'local' params from {{SecurityConfiguration}}
> need to take precedence over those present in {{SecurityProvider}}.
> However, In our new, pure Osgi setup, where there is no such
> mixed-param-setup, we would need a mandatory overwrite of e.g.
> {{RestrictionProvider}} (s) or {{AuthorizableActionProvider}} (s), because
> the _old_ values in the {{SecurityConfiguration}} had not been provided by
> it's own config but as a matter of fact refer to the old values of the
> {{SecurityProviderRegistration}}, which got unregistered and thus are stale
> service references.
> h4. Potential Fixes
> In any case we must have a unit-test that illustrates the problem and allows
> us to verify that whatever fix we apply actually addresses the problem. I
> will try to provide that today.
> h5. Variant 1
> Looking back my feeling is, that we should have moved all those extra-params
> that get pushed to the {{SecurityConfiguration}} as references to the
> modules. Not sure if/how that is feasible at the current state without
> risking too many compatibility issues and regressions.
> h5. Variant 2
> Since we no longer have a mixed java/osgi setup since the introduction of the
> {{SecurityProviderRegistration}} and removed the OSGi-annotations from the
> old (now pure java) {{SecurityProviderImpl}}, we might consider just changing
> the following call in {{SecurityProviderRegistration}} from:
> {code}base.setParameters(ConfigurationParameters.of(parameters,
> base.getParameters()));{code}
> to
> {code}base.setParameters(ConfigurationParameters.of(base.getParameters(),
> parameters));{code}
> and thus actually doing what we intend to do: replace the existing entries in
[jira] [Commented] (OAK-4566) Multiplexing store support in Lucene Indexes
[
https://issues.apache.org/jira/browse/OAK-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407419#comment-15407419
]
Chetan Mehrotra commented on OAK-4566:
--
My intention here was to ensure that getDefaultReader does not get invoked in
production code i.e. have all parts in production code adapted to work with
mounts and hence not make call to getDefaultReader. In normal setup (no mount)
existing code would work as is and no exception would be thrown. But in setup
where mount is present and say suggeter logic (yet not adapted) tries to get
the default then we throw exception to indicate this feature is yet not
complete.
Or may be we just open issue and track this missing piece and not throw
exception. For now I am think to remove this check
> Multiplexing store support in Lucene Indexes
>
>
> Key: OAK-4566
> URL: https://issues.apache.org/jira/browse/OAK-4566
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Similar to OAK-3403 we need support multiplexing store in Lucene indexes.
> This can be done by having multiple directories under given index definition.
> For e.g. currently the Lucene indexes for an index /oak:index/assetIndex are
> stored in node /oak:index/assetIndex/:dir. For supporting multiple indexes
> which get stored in different stores we can have structure like
> {noformat}
> /oak:index/assetIndex
> + :oak:mount1-dir
> + :dir
> {noformat}
> In above structure index content for paths which are part of mount1 would be
> store in Lucene files stores under {{:oak:mount1-dir}} while the rest go in
> default location {{:dir}
> # *Writing* - At the time of indexing the {{LuceneIndexEditor}} should pick
> up correct writer i.e. one which is mapped to right directory node in
> repository
> # *Reading* - For reading we would have one {{IndexSearcher}} per directory
> node and then query would be executed against both and a joined cursor would
> be made
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4640) Provide a way for commit hook to record meta data for a given commit
[
https://issues.apache.org/jira/browse/OAK-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407411#comment-15407411
]
Chetan Mehrotra commented on OAK-4640:
--
Document once added cannot be constructed back as is. For now I do not think
that in memory state consumed by such documents would be large. Further
LuceneIndexWriter can do this on best effort basis i.e. if total number of
documents accumulated for given commit exceeds say 100 then do not do that and
let documents be created on observer side. This might be the approach for large
transaction
> Provide a way for commit hook to record meta data for a given commit
>
>
> Key: OAK-4640
> URL: https://issues.apache.org/jira/browse/OAK-4640
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Currently as part of commit the caller can provide a CommitInfo instance
> which captures some metadata related to commit being performed. Note that
> CommitInfo instance passed to NodeStore is immutable.
> For some usecases we need a way to add some more metadata to on going
> commit from within the CommitHook
> * OAK-4586 - Here we need to record nodetypes of nodes which got modified as
> part of current commit
> * OAK-4412 - Here we want to generate Documents for modified nodestate (per
> index definition) and "attach" it to current commit
> This meta information would later be used by Observer.
> To enable such cases some mutable state needs to be exposed as part of
> CommitInfo which can be used by CommitHooks.
> As per discussion of DL [1] this can be done by adding a new
> {{CommitAttributes}} instance which can be accessed from {{CommitInfo}}
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk%3DTMQ_q20dPSmdr7Q%3DcR8OfMDdJceDTd-pGs0pk_cK0g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4641) Using same index definition for both async and sync indexing
[
https://issues.apache.org/jira/browse/OAK-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4641:
-
Description:
Currently one can set "async" flag on an index definition to indicate wether
given index should be effective for synchronous commit or to be used for async
indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a way where
same index definition gets used in both.
As discussed on DL [1] for this to be done following changes need to be done
# Making {{async}} as a multi value property.
# Introducing a new IndexEditorProvider interface which can accept an
IndexingContext instance. This provides access to
## indexing mode - sync or async
## index path of the index (see OAK-4152)
## CommitInfo (see OAK-4640)
[1]
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
was:
Currently one can set "async" flag on an index definition to indicate wether
given index should be effective for synchronous commit or to be used for async
indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a way where
same index definition gets used in both.
As discussed on DL [1] this can be done by
# Making {{async}} as a multi value property.
# Introducing a new IndexEditorProvider interface which can accept an
IndexingContext instance. This provides access to
## indexing mode - sync or async
## index path of the index (see OAK-4152)
## CommitInfo (see OAK-4640)
[1]
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
> Using same index definition for both async and sync indexing
>
>
> Key: OAK-4641
> URL: https://issues.apache.org/jira/browse/OAK-4641
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Currently one can set "async" flag on an index definition to indicate wether
> given index should be effective for synchronous commit or to be used for
> async indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a
> way where same index definition gets used in both.
> As discussed on DL [1] for this to be done following changes need to be done
> # Making {{async}} as a multi value property.
> # Introducing a new IndexEditorProvider interface which can accept an
> IndexingContext instance. This provides access to
> ## indexing mode - sync or async
> ## index path of the index (see OAK-4152)
> ## CommitInfo (see OAK-4640)
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407403#comment-15407403
]
Chetan Mehrotra commented on OAK-4642:
--
With O2 we modify existing {{IndexUpdateCallback}} and thus all the places
where callback gets constructed would need to be modified. Further the place
where callback gets constructed might be not be aware of all the data
(indexPath etc) So it would not be possible also
With O4 we introduce a new interface
{code}
public interface ContextAwareCallback extends IndexUpdateCallback {
IndexingContext getIndexingContext();
}
{code}
And then in {{IndexUpdate}} instead of passing a normal callback we pass an
impl of ContextAwareCallback. Then index editor provider can check if the
provided callback is of new interface then cast and get the required context.
So here the changes required are very minimal. See the [o4
patch|^OAK-4642-o4-v1.patch] for just the approach (testcase pending)
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4642:
-
Attachment: OAK-4642-o4-v1.patch
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
> Attachments: OAK-4642-o4-v1.patch
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407380#comment-15407380 ] Thomas Mueller commented on OAK-4585: - http://svn.apache.org/r1755145 (trunk) Thanks Chetan. * Path: I now mainly log the path, as I see it's better than the content identity for the SegmentStore case. I still log the content identity for the FileDataStore case, so it should be easy to get hold of the binary (and even if the repository is not available). * Trace level: I still use debug level, not sure why trace level would be better? I think people mainly use debug level when trying to find problems, and this doesn't seem to increase the log file dramatically. * Log time taken, source size, extracted text size: done * By the way there was a bug in the first patch, Long.parseLong instead of Long.getLong. > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.6, 1.5.7 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4585: Fix Version/s: 1.5.7 1.4.6 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.6, 1.5.7 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407355#comment-15407355
]
Alex Parvulescu commented on OAK-4642:
--
I'm not sure I get {{O2}} vs {{O4}}. Adding a new interface means changing the
construction code anyways, what is the gain (probably depends on the amount of
changes needed in tests)?
I'm sort of leaning towards this option (O2 or O4), but would like to see what
others think.
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4640) Provide a way for commit hook to record meta data for a given commit
[
https://issues.apache.org/jira/browse/OAK-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407351#comment-15407351
]
Alex Parvulescu commented on OAK-4640:
--
bq. OAK-4412 - Here we want to generate Documents for modified nodestate (per
index definition) and "attach" it to current commit
not sure if this would be better or not, but could you reduce the data attached
to the commit to only the doc ids? and later you could extract them from one
index and insert them into the other.
> Provide a way for commit hook to record meta data for a given commit
>
>
> Key: OAK-4640
> URL: https://issues.apache.org/jira/browse/OAK-4640
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Currently as part of commit the caller can provide a CommitInfo instance
> which captures some metadata related to commit being performed. Note that
> CommitInfo instance passed to NodeStore is immutable.
> For some usecases we need a way to add some more metadata to on going
> commit from within the CommitHook
> * OAK-4586 - Here we need to record nodetypes of nodes which got modified as
> part of current commit
> * OAK-4412 - Here we want to generate Documents for modified nodestate (per
> index definition) and "attach" it to current commit
> This meta information would later be used by Observer.
> To enable such cases some mutable state needs to be exposed as part of
> CommitInfo which can be used by CommitHooks.
> As per discussion of DL [1] this can be done by adding a new
> {{CommitAttributes}} instance which can be accessed from {{CommitInfo}}
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk%3DTMQ_q20dPSmdr7Q%3DcR8OfMDdJceDTd-pGs0pk_cK0g%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4641) Using same index definition for both async and sync indexing
[
https://issues.apache.org/jira/browse/OAK-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407350#comment-15407350
]
Alex Parvulescu commented on OAK-4641:
--
just to clarify {{1}} and {{2}} would _both_ be required, those are not options
to choose from.
> Using same index definition for both async and sync indexing
>
>
> Key: OAK-4641
> URL: https://issues.apache.org/jira/browse/OAK-4641
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Currently one can set "async" flag on an index definition to indicate wether
> given index should be effective for synchronous commit or to be used for
> async indexing. For Hybrid Lucene indexing case OAK-4412 we need to have a
> way where same index definition gets used in both.
> As discussed on DL [1] this can be done by
> # Making {{async}} as a multi value property.
> # Introducing a new IndexEditorProvider interface which can accept an
> IndexingContext instance. This provides access to
> ## indexing mode - sync or async
> ## index path of the index (see OAK-4152)
> ## CommitInfo (see OAK-4640)
> [1]
> http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201608.mbox/%3CCAHCW-mk1HzAxy8fk17SzYDcfLYY%3D0HUp93FCYoxpTP37cNgb%2Bg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4566) Multiplexing store support in Lucene Indexes
[
https://issues.apache.org/jira/browse/OAK-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407347#comment-15407347
]
Alex Parvulescu commented on OAK-4566:
--
Patch looks good as far as I can tell.
One small question is related to the impl of {{IndexNode#getDefaultReader()}},
why does it need to verify {{Preconditions.checkArgument(readers.size() ==
1}}, can't it simply just pickup the first entry if the list is non-empty (that
would be the default mount anyway, no)? [0]
[0]
https://github.com/chetanmeh/jackrabbit-oak/blob/f73df0d4d4288ae90ab29b3ca7e5939b8a14da1c/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/IndexNode.java#L116
> Multiplexing store support in Lucene Indexes
>
>
> Key: OAK-4566
> URL: https://issues.apache.org/jira/browse/OAK-4566
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> Similar to OAK-3403 we need support multiplexing store in Lucene indexes.
> This can be done by having multiple directories under given index definition.
> For e.g. currently the Lucene indexes for an index /oak:index/assetIndex are
> stored in node /oak:index/assetIndex/:dir. For supporting multiple indexes
> which get stored in different stores we can have structure like
> {noformat}
> /oak:index/assetIndex
> + :oak:mount1-dir
> + :dir
> {noformat}
> In above structure index content for paths which are part of mount1 would be
> store in Lucene files stores under {{:oak:mount1-dir}} while the rest go in
> default location {{:dir}
> # *Writing* - At the time of indexing the {{LuceneIndexEditor}} should pick
> up correct writer i.e. one which is mapped to right directory node in
> repository
> # *Reading* - For reading we would have one {{IndexSearcher}} per directory
> node and then query would be executed against both and a joined cursor would
> be made
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4642:
-
Description:
An index editor needs access to some more data points like below in the
indexing process
# reindexing - Currently the index implementation use some heuristic like check
before root state being empty to determine if they are running in reindexing
mode
# indexing mode - sync or async
# index path of the index (see OAK-4152)
# CommitInfo (see OAK-4640)
For this we need to provide a way to pass these data points from indexing flow.
We have following options
* O1 - Introduce a new interface which takes an {{IndexingContext}} instance
which provide access to such datapoints. This would require some broader change
** Whereever the IndexEditorProvider is invoked it would need to check if the
instance implements new interface. If yes then new method needs to be used
* O2 - Here we can introduce such data points as part of callback interface.
With this we would need to implement such methods in places where code
constructs the callback
* O3 - Make a backward incompatible change and just modify the existing
interface and adapt the various implementation
* O4 - Similar to O2 but here instead of modifying the existing
{{IndexUpdateCallback}} we can introduce a new interface {{ContextualCallback}}
which extends {{IndexUpdateCallback}} and provide access to
{{IndexingContext}}. Editor provider implementation can then check if the
callback implements this new interface and then cast it and access the context.
So only those client which are interested in new capability make use of this
was:
An index editor needs access to some more data points like below in the
indexing process
# reindexing - Currently the index implementation use some heuristic like check
before root state being empty to determine if they are running in reindexing
mode
# indexing mode - sync or async
# index path of the index (see OAK-4152)
# CommitInfo (see OAK-4640)
For this we need to provide a way to pass these data points from indexing flow
* Approach 1 - Introduce a new interface which takes an {{IndexingContext}}
instance which provide access to such datapoints. This would require some
broader change
** Whereever the IndexEditorProvider is invoked it would need to check if the
instance implements new interface. If yes then new method needs to be used
* Approach 2 - Here we can introduce such data points as part of callback
interface. With this we would need to implement such methods in places where
code constructs the callback
* Approach 3 - Make a backward incompatible change and just modify the existing
interface and adapt the various implementation
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing
> flow. We have following options
> * O1 - Introduce a new interface which takes an {{IndexingContext}} instance
> which provide access to such datapoints. This would require some broader
> change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * O2 - Here we can introduce such data points as part of callback interface.
> With this we would need to implement such methods in places where code
> constructs the callback
> * O3 - Make a backward incompatible change and just modify the existing
> interface and adapt the various implementation
> * O4 - Similar to O2 but here instead of modifying the existing
> {{IndexUpdateCallback}} we can introduce a new interface
> {{ContextualCallback}} which extends {{IndexUpdateCallback}} and provide
> access to {{IndexingContext}}. Editor provider implementation can then check
> if the callback implements this new interface and then cast it and access the
> context. So only those client which are interested in new capability make use
> of this
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4642:
-
Description:
An index editor needs access to some more data points like below in the
indexing process
# reindexing - Currently the index implementation use some heuristic like check
before root state being empty to determine if they are running in reindexing
mode
# indexing mode - sync or async
# index path of the index (see OAK-4152)
# CommitInfo (see OAK-4640)
For this we need to provide a way to pass these data points from indexing flow
* Approach 1 - Introduce a new interface which takes an {{IndexingContext}}
instance which provide access to such datapoints. This would require some
broader change
** Whereever the IndexEditorProvider is invoked it would need to check if the
instance implements new interface. If yes then new method needs to be used
* Approach 2 - Here we can introduce such data points as part of callback
interface. With this we would need to implement such methods in places where
code constructs the callback
* Approach 3 - Make a backward incompatible change and just modify the existing
interface and adapt the various implementation
was:
An index editor needs access to some more data points like below in the
indexing process
# reindexing - Currently the index implementation use some heuristic like check
before root state being empty to determine if they are running in reindexing
mode
# indexing mode - sync or async
# index path of the index (see OAK-4152)
# CommitInfo (see OAK-4640)
For this we need to provide a way to pass these data points from indexing flow
* Approach 1 - Introduce a new interface which takes an {{IndexingContext}}
instance which provide access to such datapoints. This would require some
broader change
** Whereever the IndexEditorProvider is invoked it would need to check if the
instance implements new interface. If yes then new method needs to be used
* Approach 2 - Here we can introduce such data points as part of callback
interface. With this we would need to implement such methods in places where
code constructs the callback
For now #1 looks cleaner but may require broader change
> Provide a way to pass indexing related state to IndexEditorProvider
> ---
>
> Key: OAK-4642
> URL: https://issues.apache.org/jira/browse/OAK-4642
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.6
>
>
> An index editor needs access to some more data points like below in the
> indexing process
> # reindexing - Currently the index implementation use some heuristic like
> check before root state being empty to determine if they are running in
> reindexing mode
> # indexing mode - sync or async
> # index path of the index (see OAK-4152)
> # CommitInfo (see OAK-4640)
> For this we need to provide a way to pass these data points from indexing flow
> * Approach 1 - Introduce a new interface which takes an {{IndexingContext}}
> instance which provide access to such datapoints. This would require some
> broader change
> ** Whereever the IndexEditorProvider is invoked it would need to check if the
> instance implements new interface. If yes then new method needs to be used
> * Approach 2 - Here we can introduce such data points as part of callback
> interface. With this we would need to implement such methods in places where
> code constructs the callback
> * Approach 3 - Make a backward incompatible change and just modify the
> existing interface and adapt the various implementation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4642) Provide a way to pass indexing related state to IndexEditorProvider
Chetan Mehrotra created OAK-4642:
Summary: Provide a way to pass indexing related state to
IndexEditorProvider
Key: OAK-4642
URL: https://issues.apache.org/jira/browse/OAK-4642
Project: Jackrabbit Oak
Issue Type: Technical task
Components: core
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Fix For: 1.6
An index editor needs access to some more data points like below in the
indexing process
# reindexing - Currently the index implementation use some heuristic like check
before root state being empty to determine if they are running in reindexing
mode
# indexing mode - sync or async
# index path of the index (see OAK-4152)
# CommitInfo (see OAK-4640)
For this we need to provide a way to pass these data points from indexing flow
* Approach 1 - Introduce a new interface which takes an {{IndexingContext}}
instance which provide access to such datapoints. This would require some
broader change
** Whereever the IndexEditorProvider is invoked it would need to check if the
instance implements new interface. If yes then new method needs to be used
* Approach 2 - Here we can introduce such data points as part of callback
interface. With this we would need to implement such methods in places where
code constructs the callback
For now #1 looks cleaner but may require broader change
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
