[jira] [Updated] (OAK-3345) SessionMBean should provide information about pending refresh
[
https://issues.apache.org/jira/browse/OAK-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3345:
Fix Version/s: (was: 1.1.7)
1.0.20
> SessionMBean should provide information about pending refresh
> -
>
> Key: OAK-3345
> URL: https://issues.apache.org/jira/browse/OAK-3345
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Labels: gc, monitoring
> Fix For: 1.0.20
>
>
> The session auto refresh feature is implemented by marking sessions pending
> for refresh. The refresh operation itself however only happens on the next
> access to the session.
> It would be helpful if {{SessionMBean}} could expose the information whether
> a session has a pending refresh. Additionally we could expose the current
> {{RefreshStrategy}} to make the auto refresh behaviour more transparent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3134: --- Description: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-development| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | | | Standby | | | | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | was: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | | scalability benchmark | org.apache.jackrabbit.oak.scalability | | | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | | Backup | | | | Restore | | | | Debug | | | | Check | | | | Compact | | | | Server | | | | Upgrade | | | | Explore | | | | Primary | | | | Standby | | | | Help | | | | Checkpoints | | | | Recovery | | | | Repair | | | | Tika | | | > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-development| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | | > | Standby | | | > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3345) SessionMBean should provide information about pending refresh
[
https://issues.apache.org/jira/browse/OAK-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-3345.
-
Resolution: Fixed
> SessionMBean should provide information about pending refresh
> -
>
> Key: OAK-3345
> URL: https://issues.apache.org/jira/browse/OAK-3345
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Labels: gc, monitoring
> Fix For: 1.0.20
>
>
> The session auto refresh feature is implemented by marking sessions pending
> for refresh. The refresh operation itself however only happens on the next
> access to the session.
> It would be helpful if {{SessionMBean}} could expose the information whether
> a session has a pending refresh. Additionally we could expose the current
> {{RefreshStrategy}} to make the auto refresh behaviour more transparent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3347) Ineffective cleanup after compaction due to references to root
[
https://issues.apache.org/jira/browse/OAK-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-3347.
Resolution: Fixed
Fix Version/s: 1.3.6
Fixed at http://svn.apache.org/r1701239
> Ineffective cleanup after compaction due to references to root
> --
>
> Key: OAK-3347
> URL: https://issues.apache.org/jira/browse/OAK-3347
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: cleanup, compac, gc
> Fix For: 1.3.6
>
>
> The cleanup phase after a compaction run is currently not able to remove the
> pre compacted segments as the previous (pre-compacted) root is still being
> referenced. Those references are coming from:
> * The {{before}} [local
> variable|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L653]
> in {{FileStore.flush}}.
> * The [current
> head|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStore.java#L85-L85]
> of the {{SegmentNodeStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2712) Possible null-dereference when calling ItemImpl#perform
[
https://issues.apache.org/jira/browse/OAK-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-2712:
Fix Version/s: 1.0.20
> Possible null-dereference when calling ItemImpl#perform
> ---
>
> Key: OAK-2712
> URL: https://issues.apache.org/jira/browse/OAK-2712
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.4, 1.0.19
>Reporter: angela
>Assignee: angela
> Labels: technical_debt
> Fix For: 1.3.0, 1.0.20, 1.2.5
>
>
> FindBugs complains about usages of ItemImpl#perform that is annotated with
> {{@CheckForNull}} but callers expecting a non-null return value most
> prominently in NodeImpl
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3251) speeding up the build time
[
https://issues.apache.org/jira/browse/OAK-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730655#comment-14730655
]
Chetan Mehrotra commented on OAK-3251:
--
bq. org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
Should be fine. Most of the logic has direct testcase support in other test in
oak-lucene
> speeding up the build time
> --
>
> Key: OAK-3251
> URL: https://issues.apache.org/jira/browse/OAK-3251
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Attachments: build-1441353866-times.log, build-1441353866.log,
> oak-build-for-unittests-times.log, oak-build-times.log
>
>
> Running the build with a {mvn clean install} takes a considerable amount of
> time: 15 minutes on my local.
> The top 10 slowest unit test are the following
> {noformat}
> 110.822 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
> 54.012 sec
> org.apache.jackrabbit.oak.plugins.segment.SegmentDataStoreBlobGCTest
> 36.593 sec
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollectorTest
> 35.234 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
> 25.047 sec org.apache.jackrabbit.oak.plugins.segment.file.FileStoreTest
> 24.787 sec org.apache.jackrabbit.oak.plugins.document.BasicDocumentStoreTest
> 17.477 sec org.apache.jackrabbit.oak.plugins.segment.ExternalBlobTest
> 16.343 sec org.apache.jackrabbit.oak.jcr.query.QueryTest
> 14.519 sec org.apache.jackrabbit.oak.plugins.segment.CompactionAndCleanupTest
> 11.604 sec org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> {noformat}
> Is there anything we could do to speed-up these?
> sorted times obtained with
> https://gist.github.com/davidegiannella/b1d3cbe51d1f70314500
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3350) Incremental compaction
[ https://issues.apache.org/jira/browse/OAK-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3350: --- Summary: Incremental compaction (was: Imcremental compaction) > Incremental compaction > -- > > Key: OAK-3350 > URL: https://issues.apache.org/jira/browse/OAK-3350 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.3.6 > > > This is OAK-3349 taken to the extreme: given a segment that is almost not > referenced any more we could just rewrite the still referenced content. That > is, say a segment contains two properties reachable from the current root > node state and all its remaining content is not reachable from the root node > state. In that case we could rewrite these two properties and create a new > root node state referencing the rewritten properties. This would effectively > make the segment eligible for being gc-ed. > Such an approach would start from segments that are sparse and compact these > instead of compacting everything as we currently do, which might cause a lot > of copying around stuff that already is compact. The challenging part here is > probably finding the segments that are sparse as this involves inverting the > reference graph. > Todo: Asses feasibility and impact, implement prototype. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3134: -- Description: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || New module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | | scalability benchmark | org.apache.jackrabbit.oak.scalability | | | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | Backup | | | Restore | | | Debug | | | Check | | | Compact | | | Server | | | Upgrade | | | Explore | | | Primary | | | Standby | | | Help | | | Checkpoints | | | Recovery | | | Repair | | | Tika | | was: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | scalability benchmark | org.apache.jackrabbit.oak.scalability | | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | Backup | | | Restore | | | Debug | | | Check | | | Compact | | | Server | | | Upgrade | | | Explore | | | Primary | | | Standby | | | Help | | | Checkpoints | | | Recovery | | | Repair | | | Tika | | > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || New module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | > | Backup | | > | Restore | | > | Debug | | > | Check | | > | Compact | | > | Server | | > | Upgrade | | > | Explore | | > | Primary | | > | Standby | | > | Help | | > | Checkpoints | | > | Recovery | | > | Repair | | > | Tika | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella reassigned OAK-3134: - Assignee: Davide Giannella > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | > | Backup | | | > | Restore | | | > | Debug | | | > | Check | | | > | Compact | | | > | Server | | | > | Upgrade | | | > | Explore | | | > | Primary | | | > | Standby | | | > | Help | | | > | Checkpoints | | | > | Recovery | | | > | Repair | | | > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3134: -- Description: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | | scalability benchmark | org.apache.jackrabbit.oak.scalability | | | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | | Backup | | | | Restore | | | | Debug | | | | Check | | | | Compact | | | | Server | | | | Upgrade | | | | Explore | | | | Primary | | | | Standby | | | | Help | | | | Checkpoints | | | | Recovery | | | | Repair | | | | Tika | | | was: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || New module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | | scalability benchmark | org.apache.jackrabbit.oak.scalability | | | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | Backup | | | Restore | | | Debug | | | Check | | | Compact | | | Server | | | Upgrade | | | Explore | | | Primary | | | Standby | | | Help | | | Checkpoints | | | Recovery | | | Repair | | | Tika | | > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | > | Backup | | | > | Restore | | | > | Debug | | | > | Check | | | > | Compact | | | > | Server | | | > | Upgrade | | | > | Explore | | | > | Primary | | | > | Standby | | | > | Help | | | > | Checkpoints | | | > | Recovery | | | > | Repair | | | > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2849) Improve revision gc on SegmentMK
[ https://issues.apache.org/jira/browse/OAK-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-2849: --- Issue Type: Epic (was: Task) > Improve revision gc on SegmentMK > > > Key: OAK-2849 > URL: https://issues.apache.org/jira/browse/OAK-2849 > Project: Jackrabbit Oak > Issue Type: Epic > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.3.6 > > Attachments: SegmentCompactionIT-conflicts.png > > > This is a container issue for the ongoing effort to improve revision gc of > the SegmentMK. > I'm exploring > * ways to make the reference graph as exact as possible and necessary: it > should not contain segments that are not referenceable any more and but must > contain all segments that are referenceable. > * ways to segregate the reference graph reducing dependencies between certain > set of segments as much as possible. > * Reducing the number of in memory references and their impact on gc as much > as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3350) Imcremental compaction
Michael Dürig created OAK-3350: -- Summary: Imcremental compaction Key: OAK-3350 URL: https://issues.apache.org/jira/browse/OAK-3350 Project: Jackrabbit Oak Issue Type: Sub-task Components: segmentmk Reporter: Michael Dürig Assignee: Michael Dürig This is OAK-3349 taken to the extreme: given a segment that is almost not referenced any more we could just rewrite the still referenced content. That is, say a segment contains two properties reachable from the current root node state and all its remaining content is not reachable from the root node state. In that case we could rewrite these two properties and create a new root node state referencing the rewritten properties. This would effectively make the segment eligible for being gc-ed. Such an approach would start from segments that are sparse and compact these instead of compacting everything as we currently do, which might cause a lot of copying around stuff that already is compact. The challenging part here is probably finding the segments that are sparse as this involves inverting the reference graph. Todo: Asses feasibility and impact, implement prototype. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3351) Add ability to prioritise restriction to where it matches
Tobias Bocanegra created OAK-3351:
-
Summary: Add ability to prioritise restriction to where it matches
Key: OAK-3351
URL: https://issues.apache.org/jira/browse/OAK-3351
Project: Jackrabbit Oak
Issue Type: Improvement
Components: security
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
Consider the following use case:
A node, and not its subtree, should be protected from removal, if it contains a
defined property. a custom jcr:protected so to speak.
The idea is to create a restriction provider that enables the ACE when the
property is set. for example:
{noformat}
allow rep:read,rep:write /a
deny jcr:removeNode /a hasProperty=protect-me
allow jcr:removeNode /a hasProperty=!protect-me
{noformat}
the _allow_ is needed so that the child nodes of a protected node are still
removable, if they are not protected themselves.
The problem is now, that the ACE does not apply where it matches, but where it
is defined.
so assume we have a node {{/a/b/c}} protected. the ACE in {{/a}} would then
match the node, but also the parent {{/a/b}} if it is not protected would match
the allow rule, since the REMOVE_NODE is a permission that also needs to check
the REMOVE_CHILDNODES privilege on the parent. And since the allow ACE is after
the deny one, it wins.
So either the parent-check needs to be delayed to a later stage, or we can
define that an ACE with restriction can be sorted in a way that it applies
where it matches, so that it looks like the ACE was specified on {{/a/b/c}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3134: -- Issue Type: Epic (was: Task) > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark | | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | > | Backup | | | > | Restore | | | > | Debug | | | > | Check | | | > | Compact | | | > | Server | | | > | Upgrade | | | > | Explore | | | > | Primary | | | > | Standby | | | > | Help | | | > | Checkpoints | | | > | Recovery | | | > | Repair | | | > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2714) Test failures on Jenkins
[ https://issues.apache.org/jira/browse/OAK-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-2714: --- Description: This issue is for tracking test failures seen at our Jenkins instance that might yet be transient. Once a failure happens too often we should remove it here and create a dedicated issue for it. || Test || Builds || Fixture || JVM || | org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.reuseLocalDir | 81 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.jcr.OrderedIndexIT.oak2035 | 76, 128 | SEGMENT_MK , DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.plugins.segment.standby.StandbyTestIT.testSyncLoop | 64 | ?| ? | | org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobStore | 52, 181 | DOCUMENT_NS | 1.7 | | org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar | 41 | ?| ? | | org.apache.jackrabbit.test.api.observation.PropertyAddedTest.testMultiPropertyAdded | 29 | ?| ? | | org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite | 35 | SEGMENT_MK | ? | | org.apache.jackrabbit.oak.jcr.query.QueryPlanTest.propertyIndexVersusNodeTypeIndex | 90 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTest.removeSubtreeFilter | 94 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTest.disjunctPaths | 121, 157 | DOCUMENT_RDB | 1.6, 1.8 | | org.apache.jackrabbit.oak.jcr.ConcurrentFileOperationsTest.concurrent | 110, 382 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.MoveRemoveTest.removeExistingNode | 115 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.jcr.RepositoryTest.addEmptyMultiValue | 115 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.stats.ClockTest.testClockDriftFast | 115, 142 | SEGMENT_MK, DOCUMENT_NS | 1.6, 1.8 | | org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT | 142, 186, 191 | DOCUMENT_RDB, SEGMENT_MK | 1.6 | | org.apache.jackrabbit.oak.plugins.index.solr.query.SolrQueryIndexTest | 148, 151 | SEGMENT_MK, DOCUMENT_NS, DOCUMENT_RDB | 1.6, 1.7, 1.8 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTest.testReorder | 155 | DOCUMENT_RDB | 1.8 | | org.apache.jackrabbit.oak.osgi.OSGiIT.bundleStates | 163 | SEGMENT_MK | 1.6 | | org.apache.jackrabbit.oak.plugins.segment.standby.ExternalSharedStoreIT | 163, 164 | SEGMENT_MK, DOCUMENT_RDB | 1.7, 1.8 | | org.apache.jackrabbit.oak.jcr.query.SuggestTest | 171 | SEGMENT_MK | 1.8 | | org.apache.jackrabbit.oak.jcr.nodetype.NodeTypeTest.updateNodeType | 243 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.query.QueryPlanTest.nodeType | 272 | DOCUMENT_RDB | 1.8 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTesttestMove | 308 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.version.VersionablePathNodeStoreTest.testVersionablePaths | 361 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteServiceTest | 361 | DOCUMENT_NS, SEGMENT_MK | 1.8 | | org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords | 389, 392 | SEGMENT_MK, DOCUMENT_NS, DOCUMENT_RDB | 1.6, 1.7, 1.8 | was: This issue is for tracking test failures seen at our Jenkins instance that might yet be transient. Once a failure happens too often we should remove it here and create a dedicated issue for it. || Test || Builds || Fixture || JVM || | org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.reuseLocalDir | 81 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.jcr.OrderedIndexIT.oak2035 | 76, 128 | SEGMENT_MK , DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.plugins.segment.standby.StandbyTestIT.testSyncLoop | 64 | ?| ? | | org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobStore | 52, 181 | DOCUMENT_NS | 1.7 | | org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar | 41 | ?| ? | | org.apache.jackrabbit.test.api.observation.PropertyAddedTest.testMultiPropertyAdded | 29 | ?| ? | | org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite | 35 | SEGMENT_MK | ? | | org.apache.jackrabbit.oak.jcr.query.QueryPlanTest.propertyIndexVersusNodeTypeIndex | 90 | DOCUMENT_RDB | 1.6 | |
[jira] [Commented] (OAK-3144) Support multivalue user properties for Ldap users
[
https://issues.apache.org/jira/browse/OAK-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730673#comment-14730673
]
Konrad Windszus commented on OAK-3144:
--
Updated PR 33 (https://github.com/apache/jackrabbit-oak/pull/33) to fix the
failing test.
> Support multivalue user properties for Ldap users
> -
>
> Key: OAK-3144
> URL: https://issues.apache.org/jira/browse/OAK-3144
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-ldap
>Affects Versions: 1.3.3
>Reporter: Konrad Windszus
>Assignee: Manfred Baedke
> Fix For: 1.3.6, 1.2.5
>
>
> Currently the {{ExternalUser.getProperties}} only exposes single value
> properties (or in case of multiple values in the LDAP only the first value).
> The problem is the code {{LdapIdentityProvider.createUser()}}
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-ldap/src/main/java/org/apache/jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java#L711).
> This only uses
> http://directory.apache.org/api/gen-docs/latest/apidocs/org/apache/directory/api/ldap/model/entry/Attribute.html#getString%28%29
> which returns the first value only. One has to leverage the iterator
> implemented by each attribute object to get all values!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3324) hasPermission does not reflect actual behavior with restrictions
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730683#comment-14730683
]
Tobias Bocanegra commented on OAK-3324:
---
just realised the difference between {{hasPrivilege()}} and {{isGranted()}} -
so the test was wrong.
added updated test in r1701223.
however, there is still an inconsistency in the way how restrictions are
evaluated.
in the the case of:
{noformat}
testuser allow rep:read,rep:write /testroot
testuser deny jcr:removeNode /testroot/a glob=*/c
testuser allow jcr:removeNode /testroot/a glob=*/b
{noformat}
the user is granted REMOVE_NODE on /a/b/c, since the evaluation considers both
entries on /testroot/a, when it checks the parent of 'c' (because the
REMOVE_NODE requires a check of the parent).
but the user is not granted REMOVE_NODE on /a/b/c/d, since the evaluation
aborts after it encounters the deny.
see
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/security/authorization/restriction/PermissionTest.java#L150
> hasPermission does not reflect actual behavior with restrictions
>
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3324:
--
Summary: Evaluation with restriction is not consistent with parent ACLs
(was: hasPermission does not reflect actual behavior with restrictions)
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3310) Write operations on Property do not check checked-out state of Node
[ https://issues.apache.org/jira/browse/OAK-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3310: Fix Version/s: 1.0.10 > Write operations on Property do not check checked-out state of Node > --- > > Key: OAK-3310 > URL: https://issues.apache.org/jira/browse/OAK-3310 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.0.20, 1.3.6, 1.2.5 > > Attachments: OAK-3310.diff > > > Write operations on Property do not check the checked-out state. The same is > true for Node.setProperty(..., null). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3310) Write operations on Property do not check checked-out state of Node
[ https://issues.apache.org/jira/browse/OAK-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-3310. - Resolution: Fixed Fix Version/s: (was: 1.0.10) 1.0.20 > Write operations on Property do not check checked-out state of Node > --- > > Key: OAK-3310 > URL: https://issues.apache.org/jira/browse/OAK-3310 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.0.20, 1.3.6, 1.2.5 > > Attachments: OAK-3310.diff > > > Write operations on Property do not check the checked-out state. The same is > true for Node.setProperty(..., null). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730876#comment-14730876
]
Tobias Bocanegra commented on OAK-3324:
---
I think we need to define how the restrictions should work. doe they work like
virtual ACEs where ever they match,
or if they work, where they are defined, but activated if an item matches them.
further we need to define, if they inherit the permissions down like normal
ACEs.
for example, consider this test:
{noformat}
// allow rep:write /testroot
// deny jcr:modifyProperties /testroot/a glob=*/c
{noformat}
this currently evaluates like this:
{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}
so the D and E nodes are not affected by the restriction that is effective on
C. If this is the desired behavior, it should also work like this for
REMOVE_NODE and ADD_NODE.
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-3134: - Description: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-operations| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | oak-development| | Standby | | oak-development| | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | was: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | | | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-development| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | | | Standby | | | | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3325) MissingIndexProviderStrategy should warn when setting the reindex flag
[ https://issues.apache.org/jira/browse/OAK-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-3325: - Attachment: OAK-3325.patch proposed patch. I still need to fix the OSGi package export version. [~chetanm] thoughts? > MissingIndexProviderStrategy should warn when setting the reindex flag > -- > > Key: OAK-3325 > URL: https://issues.apache.org/jira/browse/OAK-3325 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Fix For: 1.3.6 > > Attachments: OAK-3325.patch > > > Currently the _MissingIndexProviderStrategy_ would silently flip the reindex > flag on missing provider types. We need to add some warning logs to know when > this happens for the synchronous indexes too. > [0] > https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/IndexUpdate.java#L323 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3134: -- Description: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-operations| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | oak-development| | Standby | | oak-development| | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | Modules left after the actions: **oak-development** Used to group and execute all the tools used during development. _deployed to maven:_ No. **oak-operations** Used to group and execute all the tools used normally in production environment for tasks like maintenance & C. _deployed to maven:_ Yes. **oak-run** Will group what's left after the split. _deployed to maven:_ No. **oak-upgrade** Will group tools for upgrading/migrating from one repo/version to another _deployed to maven:_ yes. was: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-operations| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | oak-development| | Standby | | oak-development| | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | Modules left after the actions: **oak-development** Used to group and execute all the tools used during development. _deployed to maven:_ No. **oak-operations** Used to group and execute all the tools used normally in production environment for tasks like maintenance & C. _deployed to maven:_ Yes. **oak-run** Will group what's left after the split. _deployed to maven:_ No. > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | > Modules left after the actions: > **oak-development** > Used to group and execute all the tools used during development. > _deployed to maven:_ No. > **oak-operations** > Used to group and execute all the tools used normally in production > environment for tasks like maintenance & C. > _deployed to maven:_ Yes. > **oak-run** > Will group what's left after the split. > _deployed to maven:_ No. > **oak-upgrade** > Will group
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730889#comment-14730889 ] Davide Giannella commented on OAK-3134: --- [~alex.parvulescu] arent primary and standy used in any production enviroment? (Don't really know what they are for). > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730753#comment-14730753 ] Alex Parvulescu commented on OAK-3134: -- fyi I have taken the liberty to add * console to oak-operations * debug to oak-operations * primary, standby to oak-development > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730754#comment-14730754
]
Tobias Bocanegra commented on OAK-3324:
---
improved test in r1701241.
the problem is indeed that the parent ACL is read for the REMOVE_NODE
permission.
when testing a permission that does not require the parent node ACL, like
MODIFY_PROPERTY it works.
see
org.apache.jackrabbit.oak.security.authorization.restriction.CustomRestrictionProviderTest#testProtectByRestriction
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730876#comment-14730876
]
Tobias Bocanegra edited comment on OAK-3324 at 9/4/15 2:30 PM:
---
I think we need to define how the restrictions should work. do they work like
virtual ACEs wherever they match, or are only effective where they are defined,
but activated if an item matches them.
further we need to define, if they inherit the permissions down like normal
ACEs.
for example, consider this test:
{noformat}
// allow rep:write /testroot
// deny jcr:modifyProperties /testroot/a glob=*/c
{noformat}
this currently evaluates like this:
{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}
so the D and E nodes are not affected by the restriction that is effective on
C. If this is the desired behavior, it should also work like this for
REMOVE_NODE and ADD_NODE.
the same setup with REMOVE_NODE shows this behavior:
{noformat}
assertIsGranted(pp, testRoot, true, TEST_A_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, false, TEST_D_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.REMOVE_NODE);
{noformat}
which is completely inconsistent.
was (Author: tripod):
I think we need to define how the restrictions should work. do they work like
virtual ACEs wherever they match, or are only effective where they are defined,
but activated if an item matches them.
further we need to define, if they inherit the permissions down like normal
ACEs.
for example, consider this test:
{noformat}
// allow rep:write /testroot
// deny jcr:modifyProperties /testroot/a glob=*/c
{noformat}
this currently evaluates like this:
{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}
so the D and E nodes are not affected by the restriction that is effective on
C. If this is the desired behavior, it should also work like this for
REMOVE_NODE and ADD_NODE.
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730900#comment-14730900 ] Davide Giannella commented on OAK-3134: --- Tried to summarise in the description what a module should be for and if it should be deployed to maven. I think we could end with having oak-run with basic functionality and the other modules: developemnt and operations should be able to embed and re-use the runner from oak-run if we refactor a bit (didn't look at the code details). > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | > Modules left after the actions: > **oak-development** > Used to group and execute all the tools used during development. > _deployed to maven:_ No. > **oak-operations** > Used to group and execute all the tools used normally in production > environment for tasks like maintenance & C. > _deployed to maven:_ Yes. > **oak-run** > Will group what's left after the split. > _deployed to maven:_ No. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730876#comment-14730876
]
Tobias Bocanegra edited comment on OAK-3324 at 9/4/15 2:28 PM:
---
I think we need to define how the restrictions should work. do they work like
virtual ACEs wherever they match, or are only effective where they are defined,
but activated if an item matches them.
further we need to define, if they inherit the permissions down like normal
ACEs.
for example, consider this test:
{noformat}
// allow rep:write /testroot
// deny jcr:modifyProperties /testroot/a glob=*/c
{noformat}
this currently evaluates like this:
{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}
so the D and E nodes are not affected by the restriction that is effective on
C. If this is the desired behavior, it should also work like this for
REMOVE_NODE and ADD_NODE.
was (Author: tripod):
I think we need to define how the restrictions should work. doe they work like
virtual ACEs where ever they match,
or if they work, where they are defined, but activated if an item matches them.
further we need to define, if they inherit the permissions down like normal
ACEs.
for example, consider this test:
{noformat}
// allow rep:write /testroot
// deny jcr:modifyProperties /testroot/a glob=*/c
{noformat}
this currently evaluates like this:
{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}
so the D and E nodes are not affected by the restriction that is effective on
C. If this is the desired behavior, it should also work like this for
REMOVE_NODE and ADD_NODE.
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730736#comment-14730736
]
Tobias Bocanegra commented on OAK-3324:
---
also see OAK-3351
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3156) Lucene suggestions index definition can't be restricted to a specific type of node
[
https://issues.apache.org/jira/browse/OAK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730744#comment-14730744
]
Vikas Saurabh commented on OAK-3156:
[~tmueller], [~teofili] can we get to a consensus about which approach to take:
# Make suggest queries to return paths and fix {{isVirtual}} documentation to
state that virtual rows can have non-null/non-"" paths while the semantics of
those paths are undefined
# Unsupport xpath for suggest query and remove test case + remove {{WHERE
jcr:path='/'}} conditions from sql ones (I think we'd need to update
documentation as well... not sure of its process though... do we need to
deprecate first before removing support?)
The [patch|^OAK-3156-take2.patch] implements option#1 above (without
documentation fix). If required I can prepare a patch for option#2.
> Lucene suggestions index definition can't be restricted to a specific type of
> node
> --
>
> Key: OAK-3156
> URL: https://issues.apache.org/jira/browse/OAK-3156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
> Attachments: LuceneIndexSuggestionTest.java, OAK-3156-take2.patch,
> OAK-3156.patch
>
>
> While performing a suggestor query like
> {code}
> SELECT [rep:suggest()] as suggestion FROM [nt:unstructured] WHERE
> suggest('foo')
> {code}
> Suggestor does not provide any result. In current implementation,
> [suggestions|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Suggestions]
> in Oak work only for index definitions for {{nt:base}} nodetype.
> So, an index definition like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> works, but if we change nodetype to {{nt:unstructured}} like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> , it won't work.
> The issue is that suggestor implementation essentially is passing a pseudo
> row with path=/.:
> {code:title=LucenePropertyIndex.java}
> private boolean loadDocs() {
> ...
> queue.add(new LuceneResultRow(suggestedWords));
> ...
> {code}
> and
> {code:title=LucenePropertyIndex.java}
> LuceneResultRow(Iterable suggestWords) {
> this.path = "/";
> this.score = 1.0d;
> this.suggestWords = suggestWords;
> }
> {code}
> Due to path being set to "/", {{SelectorImpl}} later filters out the result
> as {{rep:root}} (primary type of "/") isn't a {{nt:unstructured}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3327) Release Oak 1.3.5
[ https://issues.apache.org/jira/browse/OAK-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella resolved OAK-3327. --- Resolution: Fixed > Release Oak 1.3.5 > - > > Key: OAK-3327 > URL: https://issues.apache.org/jira/browse/OAK-3327 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Davide Giannella >Assignee: Davide Giannella > > - release oak > - upadate website > - upadate javadoc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3134: -- Description: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-operations| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | oak-development| | Standby | | oak-development| | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | Modules left after the actions: **oak-development** Used to group and execute all the tools used during development. _deployed to maven:_ No. **oak-operations** Used to group and execute all the tools used normally in production environment for tasks like maintenance & C. _deployed to maven:_ Yes. **oak-run** Will group what's left after the split. _deployed to maven:_ No. was: oak-run reached the size of 50MB+ and offers indeed various functionalities that could be moved to their own module. This ticket is about to identify what oak-run currently offers and what/if could be split. ML thread: http://markmail.org/thread/w34bphrk57l7pkaz || Functionality || Package || Module || | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | | scalability benchmark | org.apache.jackrabbit.oak.scalability | oak-development| | Groovy console | org.apache.jackrabbit.oak.console, /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| | Backup | | oak-operations| | Restore | | oak-operations| | Debug | | oak-operations| | Check | | oak-operations| | Compact | | oak-operations| | Server | | oak-development| | Upgrade | | oak-upgrade| | Explore | |oak-development | | Primary | | oak-development| | Standby | | oak-development| | Help | | | | Checkpoints | | oak-operations| | Recovery | | oak-operations| | Repair | | oak-operations| | Tika | | | > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | > Modules left after the actions: > **oak-development** > Used to group and execute all the tools used during development. > _deployed to maven:_ No. > **oak-operations** > Used to group and execute all the tools used normally in production > environment for tasks like maintenance & C. > _deployed to maven:_ Yes. > **oak-run** > Will group what's left after the split. > _deployed to maven:_ No. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-3324.
---
Resolution: Fixed
Fix Version/s: 1.4
fixed in r1701290 by applying the same logic to permissions that respect the
parent entry that is used for permissions that only respect the privileges on
the entry.
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4
>
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3201) Use static references in SecurityProviderImpl for composite services
[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731031#comment-14731031
]
Francesco Mari commented on OAK-3201:
-
[~anchela], I agree with you with the idea that services like
{{AuthorizableNodeName}} should not be linked directly to
{{SecurityProviderImpl}}. They should be attached directly to the components
using them, instead.
Since running a {{SecurityProvider}} without OSGi looks like an important use
case, I suggest doing a relatively simple (albeit lengthy) refactoring of
{{SecurityProviderImpl}}. The purpose of the refactoring would be to create an
implementation of {{SecurityProvider}} completely independent of OSGi. When
this implementation is in place, I can create a set of OSGi components on top
of it capable of automatically taking care of dependency injection. When the
{{SecurityProvider}} is used without OSGi, the dependencies should be
instantiated and linked manually.
This way, the {{SecurityProvider}} implementation will be cleaner, since the
code doesn't have {{@Component}} and {{@Reference}} annotations all over the
place.
What do you think?
> Use static references in SecurityProviderImpl for composite services
>
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Attachments: OAK-3201-01.patch
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency
> relationship between the {{SecurityProviderImpl}} and the required services.
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published
> before the services it requires are started, creating a window where the
> {{SecurityProviderimpl}} is operating differently from the way it's
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to
> static ones to improve the consistency of the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3348) Cross gc sessions might introduce references to pre-compacted segments
[ https://issues.apache.org/jira/browse/OAK-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730921#comment-14730921 ] Michael Dürig commented on OAK-3348: I can confirm this to be a problem. I have a test case showing the issue. Will commit it as soon as I have it in a presentable state. > Cross gc sessions might introduce references to pre-compacted segments > -- > > Key: OAK-3348 > URL: https://issues.apache.org/jira/browse/OAK-3348 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: cleanup, compaction, gc > Fix For: 1.3.6 > > > I suspect that certain write operations during compaction can cause > references from compacted segments to pre-compacted ones. This would > effectively prevent the pre-compacted segments from getting evicted in > subsequent cleanup phases. > The scenario is as follows: > * A session is opened and a lot of content is written to it such that the > update limit is exceeded. This causes the changes to be written to disk. > * Revision gc runs causing a new, compacted root node state to be written to > disk. > * The session saves its changes. This causes rebasing of its changes onto the > current root (the compacted one). At this point any node that has been added > will be added again in the sub-tree rooted at the current root. Such nodes > however might have been written to disk *before* revision gc ran and might > thus be contained in pre-compacted segments. As I suspect the node-add > operation in the rebasing process *not* to create a deep copy of such nodes > but to rather create a *reference* to them, a reference to a pre-compacted > segment is introduced here. > Going forward we need to validate above hypothesis, assess its impact if > necessary come up with a solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731071#comment-14731071
]
Tobias Bocanegra commented on OAK-3324:
---
backported to r1701297
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4, 1.0.20
>
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731071#comment-14731071
]
Tobias Bocanegra edited comment on OAK-3324 at 9/4/15 5:13 PM:
---
backported to 1.0 in r1701297
was (Author: tripod):
backported to r1701297
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4, 1.0.20
>
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
[
https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3324:
--
Fix Version/s: 1.0.20
> Evaluation with restriction is not consistent with parent ACLs
> --
>
> Key: OAK-3324
> URL: https://issues.apache.org/jira/browse/OAK-3324
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security
>Affects Versions: 1.3.4
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4, 1.0.20
>
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write /testroot
> testuser deny jcr:removeNode /testroot/a glob=*/c
> testuser allow jcr:removeNode /testroot/a glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user
> is still able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the
> user can't delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or
> the check during node deletion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3351) Add ability to prioritise restriction to where it matches
[
https://issues.apache.org/jira/browse/OAK-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3351:
--
Priority: Minor (was: Major)
> Add ability to prioritise restriction to where it matches
> -
>
> Key: OAK-3351
> URL: https://issues.apache.org/jira/browse/OAK-3351
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
>
> Consider the following use case:
> A node, and not its subtree, should be protected from removal, if it contains
> a defined property. a custom jcr:protected so to speak.
> The idea is to create a restriction provider that enables the ACE when the
> property is set. for example:
> {noformat}
> allow rep:read,rep:write /a
> deny jcr:removeNode /a hasProperty=protect-me
> allow jcr:removeNode /a hasProperty=!protect-me
> {noformat}
> the _allow_ is needed so that the child nodes of a protected node are still
> removable, if they are not protected themselves.
> The problem is now, that the ACE does not apply where it matches, but where
> it is defined.
> so assume we have a node {{/a/b/c}} protected. the ACE in {{/a}} would then
> match the node, but also the parent {{/a/b}} if it is not protected would
> match the allow rule, since the REMOVE_NODE is a permission that also needs
> to check the REMOVE_CHILDNODES privilege on the parent. And since the allow
> ACE is after the deny one, it wins.
> So either the parent-check needs to be delayed to a later stage, or we can
> define that an ACE with restriction can be sorted in a way that it applies
> where it matches, so that it looks like the ACE was specified on {{/a/b/c}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3348) Cross gc sessions might introduce references to pre-compacted segments
[ https://issues.apache.org/jira/browse/OAK-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731465#comment-14731465 ] Michael Dürig commented on OAK-3348: Test case at http://svn.apache.org/r1701329 [~alex.parvulescu], [~frm], please have a look whether you agree. > Cross gc sessions might introduce references to pre-compacted segments > -- > > Key: OAK-3348 > URL: https://issues.apache.org/jira/browse/OAK-3348 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: cleanup, compaction, gc > Fix For: 1.3.6 > > > I suspect that certain write operations during compaction can cause > references from compacted segments to pre-compacted ones. This would > effectively prevent the pre-compacted segments from getting evicted in > subsequent cleanup phases. > The scenario is as follows: > * A session is opened and a lot of content is written to it such that the > update limit is exceeded. This causes the changes to be written to disk. > * Revision gc runs causing a new, compacted root node state to be written to > disk. > * The session saves its changes. This causes rebasing of its changes onto the > current root (the compacted one). At this point any node that has been added > will be added again in the sub-tree rooted at the current root. Such nodes > however might have been written to disk *before* revision gc ran and might > thus be contained in pre-compacted segments. As I suspect the node-add > operation in the rebasing process *not* to create a deep copy of such nodes > but to rather create a *reference* to them, a reference to a pre-compacted > segment is introduced here. > Going forward we need to validate above hypothesis, assess its impact if > necessary come up with a solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3351) Add ability to prioritise restriction to where it matches
[
https://issues.apache.org/jira/browse/OAK-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14731360#comment-14731360
]
Tobias Bocanegra commented on OAK-3351:
---
see work in OAK-3324. The ACEs with restrictions don't inherit the permissions.
so the scenario above can not simple be solved with a
{noformat}
allow rep:read,rep:write /a
deny jcr:removeNode /a hasProperty=protect-me
{noformat}
rule.
> Add ability to prioritise restriction to where it matches
> -
>
> Key: OAK-3351
> URL: https://issues.apache.org/jira/browse/OAK-3351
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
>
> Consider the following use case:
> A node, and not its subtree, should be protected from removal, if it contains
> a defined property. a custom jcr:protected so to speak.
> The idea is to create a restriction provider that enables the ACE when the
> property is set. for example:
> {noformat}
> allow rep:read,rep:write /a
> deny jcr:removeNode /a hasProperty=protect-me
> allow jcr:removeNode /a hasProperty=!protect-me
> {noformat}
> the _allow_ is needed so that the child nodes of a protected node are still
> removable, if they are not protected themselves.
> The problem is now, that the ACE does not apply where it matches, but where
> it is defined.
> so assume we have a node {{/a/b/c}} protected. the ACE in {{/a}} would then
> match the node, but also the parent {{/a/b}} if it is not protected would
> match the allow rule, since the REMOVE_NODE is a permission that also needs
> to check the REMOVE_CHILDNODES privilege on the parent. And since the allow
> ACE is after the deny one, it wins.
> So either the parent-check needs to be delayed to a later stage, or we can
> define that an ACE with restriction can be sorted in a way that it applies
> where it matches, so that it looks like the ACE was specified on {{/a/b/c}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3351) Add ability to prioritise restriction to where it matches
[
https://issues.apache.org/jira/browse/OAK-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-3351.
---
Resolution: Won't Fix
> Add ability to prioritise restriction to where it matches
> -
>
> Key: OAK-3351
> URL: https://issues.apache.org/jira/browse/OAK-3351
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
>
> Consider the following use case:
> A node, and not its subtree, should be protected from removal, if it contains
> a defined property. a custom jcr:protected so to speak.
> The idea is to create a restriction provider that enables the ACE when the
> property is set. for example:
> {noformat}
> allow rep:read,rep:write /a
> deny jcr:removeNode /a hasProperty=protect-me
> allow jcr:removeNode /a hasProperty=!protect-me
> {noformat}
> the _allow_ is needed so that the child nodes of a protected node are still
> removable, if they are not protected themselves.
> The problem is now, that the ACE does not apply where it matches, but where
> it is defined.
> so assume we have a node {{/a/b/c}} protected. the ACE in {{/a}} would then
> match the node, but also the parent {{/a/b}} if it is not protected would
> match the allow rule, since the REMOVE_NODE is a permission that also needs
> to check the REMOVE_CHILDNODES privilege on the parent. And since the allow
> ACE is after the deny one, it wins.
> So either the parent-check needs to be delayed to a later stage, or we can
> define that an ACE with restriction can be sorted in a way that it applies
> where it matches, so that it looks like the ACE was specified on {{/a/b/c}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (OAK-3144) Support multivalue user properties for Ldap users
[
https://issues.apache.org/jira/browse/OAK-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella reopened OAK-3144:
---
Reopening due to failing test
Ignored failing test in https://svn.apache.org/r1701168
> Support multivalue user properties for Ldap users
> -
>
> Key: OAK-3144
> URL: https://issues.apache.org/jira/browse/OAK-3144
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-ldap
>Affects Versions: 1.3.3
>Reporter: Konrad Windszus
>Assignee: Manfred Baedke
> Fix For: 1.3.5, 1.2.5
>
>
> Currently the {{ExternalUser.getProperties}} only exposes single value
> properties (or in case of multiple values in the LDAP only the first value).
> The problem is the code {{LdapIdentityProvider.createUser()}}
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-ldap/src/main/java/org/apache/jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java#L711).
> This only uses
> http://directory.apache.org/api/gen-docs/latest/apidocs/org/apache/directory/api/ldap/model/entry/Attribute.html#getString%28%29
> which returns the first value only. One has to leverage the iterator
> implemented by each attribute object to get all values!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3144) Support multivalue user properties for Ldap users
[
https://issues.apache.org/jira/browse/OAK-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3144:
--
Fix Version/s: (was: 1.3.5)
1.3.6
> Support multivalue user properties for Ldap users
> -
>
> Key: OAK-3144
> URL: https://issues.apache.org/jira/browse/OAK-3144
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-ldap
>Affects Versions: 1.3.3
>Reporter: Konrad Windszus
>Assignee: Manfred Baedke
> Fix For: 1.3.6, 1.2.5
>
>
> Currently the {{ExternalUser.getProperties}} only exposes single value
> properties (or in case of multiple values in the LDAP only the first value).
> The problem is the code {{LdapIdentityProvider.createUser()}}
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-ldap/src/main/java/org/apache/jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java#L711).
> This only uses
> http://directory.apache.org/api/gen-docs/latest/apidocs/org/apache/directory/api/ldap/model/entry/Attribute.html#getString%28%29
> which returns the first value only. One has to leverage the iterator
> implemented by each attribute object to get all values!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730454#comment-14730454 ] Tomek Rękawek commented on OAK-3134: oak-upgrade is the backend for both oak->oak and jr2->oak migrations. My code is the command-line frontend for the oak-upgrade. But you are right - probably they should end up in the same bundle. I'll update my pull request accordingly. > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | > | Backup | | > | Restore | | > | Debug | | > | Check | | > | Compact | | > | Server | | > | Upgrade | | > | Explore | | > | Primary | | > | Standby | | > | Help | | > | Checkpoints | | > | Recovery | | > | Repair | | > | Tika | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3346) Analyze the usages of AbstractServiceTracker
[
https://issues.apache.org/jira/browse/OAK-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-3346:
Issue Type: Improvement (was: Bug)
> Analyze the usages of AbstractServiceTracker
>
>
> Key: OAK-3346
> URL: https://issues.apache.org/jira/browse/OAK-3346
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>
> A quick usage search of the AbstractServiceTracker returns the following
> information.
> {noformat}
> Class
> AbstractServiceTracker
> Found usages (11 usages found)
> Production (11 usages found)
> Usage in extends/implements clause (11 usages found)
> oak-auth-external (2 usages found)
>
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl (2
> usages found)
> ExternalIDPManagerImpl (1 usage found)
> (39: 45) public class ExternalIDPManagerImpl extends
> AbstractServiceTracker implements
> ExternalIdentityProviderManager {
> SyncManagerImpl (1 usage found)
> (40: 38) public class SyncManagerImpl extends
> AbstractServiceTracker implements SyncManager {
> oak-core (9 usages found)
> org.apache.jackrabbit.oak.spi.gc (1 usage found)
> GCMonitorTracker (1 usage found)
> (29: 39) public class GCMonitorTracker extends
> AbstractServiceTracker implements GCMonitor {
> org.apache.jackrabbit.oak.spi.whiteboard (8 usages found)
> WhiteboardAuthorizableActionProvider (1 usage found)
> (33: 17) extends
> AbstractServiceTracker
> WhiteboardAuthorizableNodeName (1 usage found)
> (29: 17) extends
> AbstractServiceTracker
> WhiteboardEditorProvider (1 usage found)
> (36: 17) extends
> AbstractServiceTracker
> WhiteboardExecutor (1 usage found)
> (30: 41) public class WhiteboardExecutor extends
> AbstractServiceTracker
> WhiteboardIndexEditorProvider (1 usage found)
> (36: 17) extends
> AbstractServiceTracker
> WhiteboardIndexProvider (1 usage found)
> (35: 17) extends
> AbstractServiceTracker
> WhiteboardRestrictionProvider (1 usage found)
> (38: 17) extends
> AbstractServiceTracker
> WhiteboardUserAuthenticationFactory (1 usage found)
> (34: 17) extends
> AbstractServiceTracker
> {noformat}
> I managed to analyze some of the implementations of AbstractServiceTracker in
> oak-core. My findings are the following.
> *WhiteboardAuthorizableActionProvider*
>
> It's supposed to enable usage of multiple AuthorizableActionProvider.
> Currently only one AuthorizableActionProvider exists in the whole stack
> (DefaultAuthorizableActionProvider). Anyway, this seems a good use case for a
> dynamic, optional, multiple reference. Why not tracking AuthorizableAction
> services directly?
> Potential unwanted effects: some events may not be picked up by every
> AuthorizableAction.
> *WhiteboardAuthorizableNodeName*
> Tracks implementations of AuthorizableNodeName. At runtime, only one
> implementation is used. There is a default implementation that is used if no
> services are registered. If a new service with a better ranking starts, it is
> automatically picked up by the WhiteboardAuthorizableNodeName.
> The AuthorizableNodeName seems to be used only when the node name of an
> authorizable entity is created. Changing this implementation at runtime
> wouldn't harm anyone. This seems a good candidate for a dynamic, optional,
> unary reference.
> Potential unwanted effects: nodes in the repository will be named with
> different strategies even if only one implementation of AuthorizableNodeName
> is started.
> *WhiteboardEditorProvider*
> Tracks implemetations of EditorProvider. Currently multiple implementations
> of this services exist. Editors are a critical part of the repository, and
> they shouldn't probably be picked up using OSGi.
> I suggest a manual instantiation of the EditorProviders, as needed, during
> the initialization of the repository. As an alternative, decouple this logic
> into a separate component.
> Potential unwanted effects: some commits will not be performed with the full
> configuration of editors. Moreover, the relative order of the editors is not
> predictable, because it is chosen by OSGi and it's unspecified.
> *WhiteboardExecutor*
> Tracks implementations of Executor. If
[jira] [Commented] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730386#comment-14730386 ] Davide Giannella commented on OAK-3134: --- [~tomek.rekawek] I can be wrong but afaiu currently oak-upgrade covers jr2->oak upgrades while your upgrade covers segment->mongo upgrade/migrations. Is it right? If so, both are as well as upgrades as migrations. Should they maybe fit in the same bundle? /cc [~reschke] > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | > | Backup | | > | Restore | | > | Debug | | > | Check | | > | Compact | | > | Server | | > | Upgrade | | > | Explore | | > | Primary | | > | Standby | | > | Help | | > | Checkpoints | | > | Recovery | | > | Repair | | > | Tika | | -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2849) Improve revision gc on SegmentMK
[ https://issues.apache.org/jira/browse/OAK-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-2849: --- Description: This is a container issue for the ongoing effort to improve revision gc of the SegmentMK. I'm exploring * ways to make the reference graph as exact as possible and necessary: it should not contain segments that are not referenceable any more and but must contain all segments that are referenceable. * ways to segregate the reference graph reducing dependencies between certain set of segments as much as possible. * Reducing the number of in memory references and their impact on gc as much as possible. was: This is a container issue for the ongoing effort to improve revision gc of the SegmentMK. I'm exploring * ways to make the reference graph as exact as possible and necessary: it should not contain segments that are not referenceable any more and but must contain all segments that are referenceable. * ways to segregate the reference graph reducing dependencies between certain set of segments as much as possible. * Reducing the number of in memory references and their impact on gc as much as possible. Work in progress is in my private [Github fork|https://github.com/mduerig/jackrabbit-oak]. As soon as something is promising enough to make it into Oak, I spawn of an issue an make it a subtask of this task. > Improve revision gc on SegmentMK > > > Key: OAK-2849 > URL: https://issues.apache.org/jira/browse/OAK-2849 > Project: Jackrabbit Oak > Issue Type: Task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.3.6 > > Attachments: SegmentCompactionIT-conflicts.png > > > This is a container issue for the ongoing effort to improve revision gc of > the SegmentMK. > I'm exploring > * ways to make the reference graph as exact as possible and necessary: it > should not contain segments that are not referenceable any more and but must > contain all segments that are referenceable. > * ways to segregate the reference graph reducing dependencies between certain > set of segments as much as possible. > * Reducing the number of in memory references and their impact on gc as much > as possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3347) Ineffective cleanup after compaction due to references to root
Michael Dürig created OAK-3347:
--
Summary: Ineffective cleanup after compaction due to references to
root
Key: OAK-3347
URL: https://issues.apache.org/jira/browse/OAK-3347
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segmentmk
Reporter: Michael Dürig
Assignee: Michael Dürig
The cleanup phase after a compaction run is currently not able to remove the
pre compacted segments as the previous (pre-compacted) root is still being
referenced. Those references are coming from:
* The {{before}} [local
variable|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L653]
in {{FileStore.flush}}.
* The [current
head|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentNodeStore.java#L85-L85]
of the {{SegmentNodeStore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3251) speeding up the build time
[
https://issues.apache.org/jira/browse/OAK-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3251:
--
Attachment: build-1441353866.log
build-1441353866-times.log
Moved the segment tests to IT and added profiling for executing them
only in case of Segment in https://svn.apache.org/r1701173
Run a full build with the following results (top 10)
{noformat}
131.114 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
58.522 sec org.apache.jackrabbit.oak.upgrade.CopyVersionHistoryTest
45.854 sec org.apache.jackrabbit.oak.upgrade.CopyVersionHistorySidegradeTest
43.176 sec
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteServiceTest
37.623 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
16.546 sec org.apache.jackrabbit.oak.jcr.query.QueryTest
11.912 sec org.apache.jackrabbit.oak.jcr.random.RandomizedReadTest
11.735 sec org.apache.jackrabbit.oak.plugins.document.BasicDocumentStoreTest
11.523 sec org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
11.358 sec org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
{noformat}
Full build in : [^build-1441353866.log]
Full test list in: [^build-1441353866-times.log]
> speeding up the build time
> --
>
> Key: OAK-3251
> URL: https://issues.apache.org/jira/browse/OAK-3251
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Attachments: build-1441353866-times.log, build-1441353866.log,
> oak-build-for-unittests-times.log, oak-build-times.log
>
>
> Running the build with a {mvn clean install} takes a considerable amount of
> time: 15 minutes on my local.
> The top 10 slowest unit test are the following
> {noformat}
> 110.822 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
> 54.012 sec
> org.apache.jackrabbit.oak.plugins.segment.SegmentDataStoreBlobGCTest
> 36.593 sec
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollectorTest
> 35.234 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
> 25.047 sec org.apache.jackrabbit.oak.plugins.segment.file.FileStoreTest
> 24.787 sec org.apache.jackrabbit.oak.plugins.document.BasicDocumentStoreTest
> 17.477 sec org.apache.jackrabbit.oak.plugins.segment.ExternalBlobTest
> 16.343 sec org.apache.jackrabbit.oak.jcr.query.QueryTest
> 14.519 sec org.apache.jackrabbit.oak.plugins.segment.CompactionAndCleanupTest
> 11.604 sec org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> {noformat}
> Is there anything we could do to speed-up these?
> sorted times obtained with
> https://gist.github.com/davidegiannella/b1d3cbe51d1f70314500
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3348) Cross gc sessions might introduce references to pre-compacted segments
Michael Dürig created OAK-3348: -- Summary: Cross gc sessions might introduce references to pre-compacted segments Key: OAK-3348 URL: https://issues.apache.org/jira/browse/OAK-3348 Project: Jackrabbit Oak Issue Type: Sub-task Components: segmentmk Reporter: Michael Dürig Assignee: Michael Dürig I suspect that certain write operations during compaction can cause references from compacted segments to pre-compacted ones. This would effectively prevent the pre-compacted segments from getting evicted in subsequent cleanup phases. The scenario is as follows: * A session is opened and a lot of content is written to it such that the update limit is exceeded. This causes the changes to be written to disk. * Revision gc runs causing a new, compacted root node state to be written to disk. * The session saves its changes. This causes rebasing of its changes onto the current root (the compacted one). At this point any node that has been added will be added again in the sub-tree rooted at the current root. Such nodes however might have been written to disk *before* revision gc ran and might thus be contained in pre-compacted segments. As I suspect the node-add operation in the rebasing process *not* to create a deep copy of such nodes but to rather create a *reference* to them, a reference to a pre-compacted segment is introduced here. Going forward we need to validate above hypothesis, assess its impact if necessary come up with a solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3309) SegmentMK segment cache loader stats
[ https://issues.apache.org/jira/browse/OAK-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3309: --- Labels: gc (was: ) > SegmentMK segment cache loader stats > > > Key: OAK-3309 > URL: https://issues.apache.org/jira/browse/OAK-3309 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segmentmk >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Labels: gc > Attachments: OAK-3309.patch > > > The existing Segment Cache has no loading-related stats, I'd like to see how > complicated it would be to add some. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3144) Support multivalue user properties for Ldap users
[
https://issues.apache.org/jira/browse/OAK-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730516#comment-14730516
]
Konrad Windszus commented on OAK-3144:
--
The test is failing with the following message
{code}
FAILED:
org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.testGetUserProperties
Error Message:
Expected: <{uid=hhornblo, mail=hhorn...@royalnavy.mod.uk, givenname=Horatio,
description=Capt. Horatio Hornblower, R.N, sn=Hornblower, cn=Horatio
Hornblower, objectclass=[top, person, organizationalPerson, inetOrgPerson]}>
got: <{uid=hhornblo, mail=hhorn...@royalnavy.mod.uk, sn=Hornblower,
cn=Horatio Hornblower, description=Capt. Horatio Hornblower, R.N,
givenname=Horatio, objectclass=[organizationalPerson, person, inetOrgPerson,
top]}>
{code}
This is due to the fact that the object classes don't have the expected order.
> Support multivalue user properties for Ldap users
> -
>
> Key: OAK-3144
> URL: https://issues.apache.org/jira/browse/OAK-3144
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-ldap
>Affects Versions: 1.3.3
>Reporter: Konrad Windszus
>Assignee: Manfred Baedke
> Fix For: 1.3.6, 1.2.5
>
>
> Currently the {{ExternalUser.getProperties}} only exposes single value
> properties (or in case of multiple values in the LDAP only the first value).
> The problem is the code {{LdapIdentityProvider.createUser()}}
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-ldap/src/main/java/org/apache/jackrabbit/oak/security/authentication/ldap/impl/LdapIdentityProvider.java#L711).
> This only uses
> http://directory.apache.org/api/gen-docs/latest/apidocs/org/apache/directory/api/ldap/model/entry/Attribute.html#getString%28%29
> which returns the first value only. One has to leverage the iterator
> implemented by each attribute object to get all values!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3309) SegmentMK segment cache loader stats
[ https://issues.apache.org/jira/browse/OAK-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730511#comment-14730511 ] Michael Dürig commented on OAK-3309: Added the gc label as revision gc is where better cache statistics is interesting. > SegmentMK segment cache loader stats > > > Key: OAK-3309 > URL: https://issues.apache.org/jira/browse/OAK-3309 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segmentmk >Reporter: Alex Parvulescu >Assignee: Alex Parvulescu > Labels: gc > Attachments: OAK-3309.patch > > > The existing Segment Cache has no loading-related stats, I'd like to see how > complicated it would be to add some. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3251) speeding up the build time
[
https://issues.apache.org/jira/browse/OAK-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14730517#comment-14730517
]
Davide Giannella commented on OAK-3251:
---
[~chetanm] oak-lucene/org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
covers regressions WRT JR2. Would that be fine for you moving it as
IT? It takes a considerable amount of time (131.114 sec) and to me it
is more an IT.
Does anyone have more insights about
- org.apache.jackrabbit.oak.upgrade.CopyVersionHistoryTest
- org.apache.jackrabbit.oak.upgrade.CopyVersionHistorySidegradeTest
> speeding up the build time
> --
>
> Key: OAK-3251
> URL: https://issues.apache.org/jira/browse/OAK-3251
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Attachments: build-1441353866-times.log, build-1441353866.log,
> oak-build-for-unittests-times.log, oak-build-times.log
>
>
> Running the build with a {mvn clean install} takes a considerable amount of
> time: 15 minutes on my local.
> The top 10 slowest unit test are the following
> {noformat}
> 110.822 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
> 54.012 sec
> org.apache.jackrabbit.oak.plugins.segment.SegmentDataStoreBlobGCTest
> 36.593 sec
> org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollectorTest
> 35.234 sec org.apache.jackrabbit.oak.jcr.query.QueryJcrTest
> 25.047 sec org.apache.jackrabbit.oak.plugins.segment.file.FileStoreTest
> 24.787 sec org.apache.jackrabbit.oak.plugins.document.BasicDocumentStoreTest
> 17.477 sec org.apache.jackrabbit.oak.plugins.segment.ExternalBlobTest
> 16.343 sec org.apache.jackrabbit.oak.jcr.query.QueryTest
> 14.519 sec org.apache.jackrabbit.oak.plugins.segment.CompactionAndCleanupTest
> 11.604 sec org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> {noformat}
> Is there anything we could do to speed-up these?
> sorted times obtained with
> https://gist.github.com/davidegiannella/b1d3cbe51d1f70314500
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3349) Partial compaction
Michael Dürig created OAK-3349: -- Summary: Partial compaction Key: OAK-3349 URL: https://issues.apache.org/jira/browse/OAK-3349 Project: Jackrabbit Oak Issue Type: Sub-task Components: segmentmk Reporter: Michael Dürig Assignee: Michael Dürig On big repositories compaction can take quite a while to run as it needs to create a full deep copy of the current root node state. For such cases it could be beneficial if we could partially compact the repository thus splitting full compaction over multiple cycles. Partial compaction would run compaction on a sub-tree just like we now run it on the full tree. Afterwards it would create a new root node state by referencing the previous root node state replacing said sub-tree with the compacted one. Todo: Asses feasibility and impact, implement prototype. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
