[jira] [Commented] (OAK-1145) [Observation] Support for EventJournal in Oak
[ https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819906#comment-13819906 ] Michael Dürig commented on OAK-1145: While the journal might seem convenient here, I don't think such a solution would scale well. For example skipping to a time stamp will force the repository to go through *all* commits rather through just the data related to the feed. Furthermore time stamps are only available for cluster local commits. In a clustered environment you thus won't be able to reliably skip to feed entries contributed on a different cluster node. As an alternative solution you could use a query (and a custom index) to get new feed entries. Such a query could either run periodically or be triggered by an observation listener, which listens on a specific property indicating the time of the latest feed entry. [Observation] Support for EventJournal in Oak - Key: OAK-1145 URL: https://issues.apache.org/jira/browse/OAK-1145 Project: Jackrabbit Oak Issue Type: New Feature Components: jcr Affects Versions: 0.10 Reporter: Daniel Platon Labels: features Fix For: 0.14 Please add support for EventJournal in Oak, as it was present in Jackrabbit 2. Thank you. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (OAK-1145) [Observation] Support for EventJournal in Oak
[ https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819911#comment-13819911 ] Daniel Platon edited comment on OAK-1145 at 11/12/13 8:18 AM: -- A query is the first thing that came to mind when I started this. However, I stumbled into the querying JCR is bad paradigm, therefore I wanted to try a more query-less approach. was (Author: dplaton): A query is the first thing that came to mind when I started this. However, I stumbled into the querying is bad paradigm, therefore I wanted to try a more query-less approach. [Observation] Support for EventJournal in Oak - Key: OAK-1145 URL: https://issues.apache.org/jira/browse/OAK-1145 Project: Jackrabbit Oak Issue Type: New Feature Components: jcr Affects Versions: 0.10 Reporter: Daniel Platon Labels: features Fix For: 0.14 Please add support for EventJournal in Oak, as it was present in Jackrabbit 2. Thank you. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1145) [Observation] Support for EventJournal in Oak
[ https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819911#comment-13819911 ] Daniel Platon commented on OAK-1145: A query is the first thing that came to mind when I started this. However, I stumbled into the querying is bad paradigm, therefore I wanted to try a more query-less approach. [Observation] Support for EventJournal in Oak - Key: OAK-1145 URL: https://issues.apache.org/jira/browse/OAK-1145 Project: Jackrabbit Oak Issue Type: New Feature Components: jcr Affects Versions: 0.10 Reporter: Daniel Platon Labels: features Fix For: 0.14 Please add support for EventJournal in Oak, as it was present in Jackrabbit 2. Thank you. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1145) [Observation] Support for EventJournal in Oak
[ https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819932#comment-13819932 ] Alexander Klimetschek commented on OAK-1145: I also don't think the EventJournal is well suited. What if the feed contains entries from last month and last year - that's an area the journal very likely won't cover anymore. A query is one solution but you might also design the content structure so that it is easy to generate the feed via traversal. [Observation] Support for EventJournal in Oak - Key: OAK-1145 URL: https://issues.apache.org/jira/browse/OAK-1145 Project: Jackrabbit Oak Issue Type: New Feature Components: jcr Affects Versions: 0.10 Reporter: Daniel Platon Labels: features Fix For: 0.14 Please add support for EventJournal in Oak, as it was present in Jackrabbit 2. Thank you. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-516) Create LdapLoginModule based on ExternalLoginModule
[ https://issues.apache.org/jira/browse/OAK-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-516: --- Priority: Major (was: Minor) Create LdapLoginModule based on ExternalLoginModule --- Key: OAK-516 URL: https://issues.apache.org/jira/browse/OAK-516 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Manfred Baedke Assignee: Tobias Bocanegra Attachments: LdapLoginModule.patch, LdapLoginTests.patch An LdapLoginModule is a natural candidate for a proof of concept of the ExternalLoginModule framework. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-127) JCR: Support for XML imports
[ https://issues.apache.org/jira/browse/OAK-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-127: --- Fix Version/s: 0.11 JCR: Support for XML imports Key: OAK-127 URL: https://issues.apache.org/jira/browse/OAK-127 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Jukka Zitting Assignee: Manfred Baedke Fix For: 0.11 Oak already supports document and system view XML exports. We need support for also importing those formats. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-127) JCR: Support for XML imports
[ https://issues.apache.org/jira/browse/OAK-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819939#comment-13819939 ] angela commented on OAK-127: IMO this topic can be resolved fixed as soon as subtask OAK-931 has been addressed. alternatively we may move OAK-931 out of this container and treat it independently. JCR: Support for XML imports Key: OAK-127 URL: https://issues.apache.org/jira/browse/OAK-127 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Jukka Zitting Assignee: Manfred Baedke Fix For: 0.11 Oak already supports document and system view XML exports. We need support for also importing those formats. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1143) [scala] Repository init throws illegal cyclic reference involving class ChangeDispatcher
[
https://issues.apache.org/jira/browse/OAK-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819955#comment-13819955
]
Michael Dürig commented on OAK-1143:
* At http://svn.apache.org/r1540981 I implemented {{ChangeDispatcher}} through
a {{CompositeObserver}} of {{BackgroundObserver}}.
* At http://svn.apache.org/r1540983 I made {{ChangeDispatcher}} implement
{{Observer}} and use the latter's {{contentChanged}} method for reporting
changes instead of the separate {{beforeCommit}}, {{localCommit}} and
{{afterCommit}} methods we had before.
[scala] Repository init throws illegal cyclic reference involving class
ChangeDispatcher
--
Key: OAK-1143
URL: https://issues.apache.org/jira/browse/OAK-1143
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Alex Parvulescu
Priority: Minor
I've been playing with Oak on Scala a bit and it looks like the latest
changes introduced a problem that makes Oak unusable.
Basically trying to setup a repo throws the following error:
{noformat}
OakRepository.scala:65: error: illegal cyclic reference involving class
ChangeDispatcher
[ERROR] new Oak(new SegmentNodeStore(new FileStore(new File(fname),
268435456, true)))
[ERROR] ^
[ERROR] one error found
{noformat}
I've simplified the code down to the most basic barebone repo init to make it
easier to digest [0].
This is a Scala bug, but my point is that this used to work prior to the
changedispacher changes, so I'm thinking we could move some bits around to
get it working from Scala again.
[0]
https://github.com/alexparvulescu/soak/blob/master/src/main/scala/com/pfalabs/soak/OakRepository.scala#L65
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1168) Invalid JCR paths not caught
Michael Dürig created OAK-1168:
--
Summary: Invalid JCR paths not caught
Key: OAK-1168
URL: https://issues.apache.org/jira/browse/OAK-1168
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, jcr
Reporter: Michael Dürig
{{NamePathMapper.getOakPath}} should return {{null}} when called with an
invalid JCR path like {{foo:bar]baz}}, but it doesn't.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1015) Optimise path parsing
[
https://issues.apache.org/jira/browse/OAK-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819974#comment-13819974
]
Michael Dürig commented on OAK-1015:
Following up with OAK-1168 instead of discussing on a closed issue.
Optimise path parsing
-
Key: OAK-1015
URL: https://issues.apache.org/jira/browse/OAK-1015
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core
Reporter: Michael Dürig
Assignee: Michael Dürig
Labels: performance
Fix For: 0.9
As Jukka [mentioned |
https://issues.apache.org/jira/browse/OAK-978?focusedCommentId=13751242page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13751242]
on OAK-978, is often on the critical path and the changes done there had a
bad impact on performance:
{code}
Apache Jackrabbit Oak
# ReadPropertyTest min 10% 50% 90% max N
Jackrabbit 4 5 5 6 14 11287
Oak-Tar 14 15 16 16 273855
{code}
Until we are able to come up with a better solution that separates parsing
from name mapping, I suggest to use the following heuristic to shortcut path
parsing: shortcut iff the JCR path does not start with a dot, does not
contain any of {}[]/ and if it contains a colon the session does not have
local re-mappings.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1168) Invalid JCR paths not caught
[
https://issues.apache.org/jira/browse/OAK-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819977#comment-13819977
]
Michael Dürig commented on OAK-1168:
(Commented out) test case at http://svn.apache.org/r1540991.
Invalid JCR paths not caught
Key: OAK-1168
URL: https://issues.apache.org/jira/browse/OAK-1168
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, jcr
Reporter: Michael Dürig
{{NamePathMapper.getOakPath}} should return {{null}} when called with an
invalid JCR path like {{foo:bar]baz}}, but it doesn't.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1161) Simple failover for TarMK-based installations
[ https://issues.apache.org/jira/browse/OAK-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819983#comment-13819983 ] Michael Marth commented on OAK-1161: Yes, I meant SegmentNodeStore with its tar file underbelly :) Simple failover for TarMK-based installations - Key: OAK-1161 URL: https://issues.apache.org/jira/browse/OAK-1161 Project: Jackrabbit Oak Issue Type: New Feature Components: segmentmk Reporter: Michael Marth At the moment we have a Mongo-based MK impl that Oak users for scalable deployments and TarMK for standalone (performant) deployments. I think it is OK to not implement some sort of scalability into TarMK, even if I realize that the hierarchical journals allow us to do that later if we want to. However, it would even now be great to have a failover option for TarMK (MongoMK implictly offers this through replicas). This would not be about clustering or scalability, but only about reliability. I think there are 2 parts to this: # keeping a standby repository (slave) in sync and # the actual fail over. For the first part there could be a relatively simple way to implement this: Let's consider that there is only one slave and that the slave does not accept writes. Given the MVCC nature of the tar files we could simply sync the (append-only) tar files from the master to the slave on an ongoing basis. This could be similar to an rsync (or even use actual rsync) The slave would keep on receiving and locally persisting these files. Also, the slave would either need to be in a state where it is blocks writes or even in some sort of sleep state. I think this synchronization of files could be done a rather robust way where shaky networks or high latency could be recovered from by choosing a proper way of transfer. This sync to a remote system could be implemented similarly than a tarMK-based incremental backup (OAK-1159). For the failover: Ideally, we would have 2 implementations: a native failover and an external switch (like MBean or via HTTP) that would make the slave stop accepting files from master and start up on the last completely received revision. But simply having the second option would be a good start. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1145) [Observation] Support for EventJournal in Oak
[
https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819989#comment-13819989
]
Michael Marth commented on OAK-1145:
{quote}
I stumbled into the querying JCR is bad paradigm, therefore I wanted to try
a more query-less approach [...]
{quote}
I think what is meant is: prefer walking the tree or leveraging hierarchy over
performing a query in JR2. This is often faster (in JR2).
It has been communicated some time in order to JCR newbies who come from a RDB
background where queries are the only way to get data. So, they would naturally
apply this habit also to JCR when in fact there are 2 ways to get data in JCR.
I agree that with Oak the situation is different than in JR2, as you say.
[Observation] Support for EventJournal in Oak
-
Key: OAK-1145
URL: https://issues.apache.org/jira/browse/OAK-1145
Project: Jackrabbit Oak
Issue Type: New Feature
Components: jcr
Affects Versions: 0.10
Reporter: Daniel Platon
Labels: features
Fix For: 0.14
Please add support for EventJournal in Oak, as it was present in Jackrabbit 2.
Thank you.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-260) Avoid the Turkish Locale Problem
[ https://issues.apache.org/jira/browse/OAK-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-260: --- Component/s: jcr core Avoid the Turkish Locale Problem -- Key: OAK-260 URL: https://issues.apache.org/jira/browse/OAK-260 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Reporter: Thomas Mueller Fix For: 0.15 We currently use String.toUpperCase() and String.toLowerCase() and in some cases where it is not appropriate. When running using the Turkish profile, this will not work as expected. See also http://mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug Problematic are String.toUpperCase(), String.toLowerCase(). String.equalsIgnoreCase(..) isn't a problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1159) Backup and restore
[ https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1159: Component/s: mk core Backup and restore -- Key: OAK-1159 URL: https://issues.apache.org/jira/browse/OAK-1159 Project: Jackrabbit Oak Issue Type: New Feature Components: core, mk Reporter: Michael Marth We need a way to backup and restore a repository. I was thinking that the MK impl could expose an interface for this, as the actual implementation would differ quite a bit between e.g. TarMK and MongoMK. Also, I think we could leverage the MVCC nature of the MKs and mark a specific revision as the revision to backup (regardless of ongoing writes). That would allow us to prevent the ugly situation in JR2, that we need to stop writes for a while to produce a consistent backup. The restore in such a scenario would discard revisions that happened after said marker (but still made it into the backup). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-103) JavaScript bindings for Oak
[ https://issues.apache.org/jira/browse/OAK-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-103: --- Component/s: core JavaScript bindings for Oak --- Key: OAK-103 URL: https://issues.apache.org/jira/browse/OAK-103 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting Labels: javascript A lot of content applications nowadays contain significant client-side functionality written largely in JavaScript and leveraging frameworks like JQuery or Backbone. JavaScript is also increasingly being used on the server. To enable easy integration with such applications Oak should come with first-class JavaScript bindings that work well with the major JavaScript frameworks. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-104) HTTP bindings for Oak
[ https://issues.apache.org/jira/browse/OAK-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-104: --- Component/s: core HTTP bindings for Oak - Key: OAK-104 URL: https://issues.apache.org/jira/browse/OAK-104 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting For easy integration with client-side JavaScript (see OAK-103) and other remote or non-Java clients Oak should come with a simple HTTP binding that avoids the extra complexity and overhead (and thus lacks the related extra functionality) of our existing JCR and WebDAV bindings. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1160) Generic interfaces for operation tasks
[ https://issues.apache.org/jira/browse/OAK-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1160: Component/s: mk core Generic interfaces for operation tasks -- Key: OAK-1160 URL: https://issues.apache.org/jira/browse/OAK-1160 Project: Jackrabbit Oak Issue Type: New Feature Components: core, mk Reporter: Michael Marth Could we add generic (i.e. MK independent) interfaces that can be used by higher levels to trigger certain ops tasks? The the application could decide when would be a good time to run them. I am thinking especially about backup/restore (OAK-1158), MVCC revision cleanup (OAK-1158) and DSGC (OAK-377) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1158) MVCC old revision cleanup
[ https://issues.apache.org/jira/browse/OAK-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1158: Component/s: mk MVCC old revision cleanup - Key: OAK-1158 URL: https://issues.apache.org/jira/browse/OAK-1158 Project: Jackrabbit Oak Issue Type: New Feature Components: mk Reporter: Michael Marth Opening this issue as OAK-114 seems mainly concerned with finding the right retention time. We need a way to clean up old MVCC revisions in order to keep the repo from growing indefinitely. Ideally, this could be done independently of the MK impl, otherwise we need it for TarMK and MongoMK -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1156) Improve the document cache invalidation logic to selectivly invalidate doc
[
https://issues.apache.org/jira/browse/OAK-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-1156:
-
Attachment: OAK-1156.patch
Patch for initial proposal.
Also pushed the changes to fork. See diff
[here|https://github.com/chetanmeh/jackrabbit-oak/compare/apache:e2e30473aff1f350e055b81fe4a5986a1cba4b0d...OAK-1156]
Improve the document cache invalidation logic to selectivly invalidate doc
--
Key: OAK-1156
URL: https://issues.apache.org/jira/browse/OAK-1156
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mongomk
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Attachments: OAK-1156.patch
Currently the Background Read operation invalidates the complete cache in
{{MongoNodeStore}} upon detecting external change. Instead of that it should
check for which cached documents are stale and only invalidate them.
It can make use of {{_lastRev}} to check if nodes within a subtree have
changed or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (OAK-1156) Improve the document cache invalidation logic to selectivly invalidate doc
[
https://issues.apache.org/jira/browse/OAK-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818854#comment-13818854
]
Chetan Mehrotra edited comment on OAK-1156 at 11/12/13 10:57 AM:
-
There are multiple approaches possible
*Approach A*
# Find the {{_modCount}} for all the cached documents using Mongo In query
# Then invalidate those entries where the Mod count differs
Approach A is more like brute force and might take quite a bit of time if the
number of cached entries are quite high
*Approach B*
# Create a tree structure out of the paths of the cached documents
# Start traversing the tree in breadth first mode and fetch the {{_lastRev}}
data for the nodes at same level
# If the last revision is same as the one in the cached document then in some
cases it can be considered that all nodes under that path have not been
modified. So we mark such cached documents as up-to-date and filter them out
from the traversal. Any child node would be considered uptodate only if either
## The in memory creation time of the child node is greater than the creation
time of root node which is found to be uptodate. So if /a/b is found to be
valid (lastRev not changed) then a child node like /a/b/c/d would be also be
considered uptodate if its creation time is greater than /a/b creation time as
then it would have been added later in the cache.
## OR the last check time for both /a/b and /a/b/c/d are same. This means that
previous run would have checked that both nodes are consistent and /a/b lastRev
can be taken as authorative source for state of this child node
In this approach we can save on lots of queries as in most cases the major
portion of tree might not have got changed. However we need to be carefull to
not to leave any stale entry in the cache. For example when ever we add a new
document to cache say at path {{/foo/bar}} it would have latest {{_lastRev}}
entry. However the already cached doc under that path would not be check in
that flow. So in above flow we might falsefully consider that tree under
{{/foo/bar}} is consistent and thus hold a stale copy
was (Author: chetanm):
There are multiple approaches possible
*Approach A*
# Find the {{_modCount}} for all the cached documents using Mongo In query
# Then invalidate those entries where the Mod count differs
Approach A is more like brute force and might take quite a bit of time if the
number of cached entries are quite high
*Approach B*
# Create a tree structure out of the paths of the cached documents
# Start traversing the tree in breadth first mode and fetch the {{_lastRev}}
data for the nodes at same level
# If the last revision is same as the one in the cached document then in some
cases it can be considered that all nodes under that path have not been
modified. So we mark such cached documents as up-to-date and filter them out
from the traversal
In this approach we can save on lots of queries as in most cases the major
portion of tree might not have got changed. However we need to be carefull to
not to leave any stale entry in the cache. For example when ever we add a new
document to cache say at path {{/foo/bar}} it would have latest {{_lastRev}}
entry. However the already cached doc under that path would not be check in
that flow. So in above flow we might falsefully consider that tree under
{{/foo/bar}} is consistent and thus hold a stale copy
Improve the document cache invalidation logic to selectivly invalidate doc
--
Key: OAK-1156
URL: https://issues.apache.org/jira/browse/OAK-1156
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mongomk
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Attachments: OAK-1156.patch
Currently the Background Read operation invalidates the complete cache in
{{MongoNodeStore}} upon detecting external change. Instead of that it should
check for which cached documents are stale and only invalidate them.
It can make use of {{_lastRev}} to check if nodes within a subtree have
changed or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-901) Test root node type is not reported correctly
[ https://issues.apache.org/jira/browse/OAK-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820019#comment-13820019 ] angela commented on OAK-901: IMO it's pretty clear: the only node that has rep:root as declaring node type is /jcr:system. all the other child nodes of the root are defined by the nt:unstructured super type and thus should report nt:unstructured as declaring node type. so, i suspect that this problem is not limited to the children of the root node but applies for all nodes as most probable the implementation behaves differently on how the declaring node type is determined. IMO we should fix that in general not just for that specific case. Test root node type is not reported correctly - Key: OAK-901 URL: https://issues.apache.org/jira/browse/OAK-901 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Reporter: Alex Parvulescu Assignee: Jukka Zitting Fix For: 0.14 The test root used in the jcr tests is created as _nt:unstructured_ but calling _testRootNode.getDefinition().getDeclaringNodeType().getName()_ will wrongfully return _rep:root_ (the node type of the repository root) This also influences the OAK-900 tests, namely the _ReorderTest_ which will throw an _NotExecutableException_ on account of the wrong node type. I'll shortly add a test. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-319) Similar (rep:similar) support
[
https://issues.apache.org/jira/browse/OAK-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-319:
---
Component/s: query
Similar (rep:similar) support
-
Key: OAK-319
URL: https://issues.apache.org/jira/browse/OAK-319
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: jcr, query
Reporter: Alex Parvulescu
Fix For: 0.12
Test class is: SimilarQueryTest
Trace:
{noformat}
Caused by: java.text.ParseException: Query:
//*[rep:similar(.(*), '/testroot')]; expected: rep:similar is not supported
at
org.apache.jackrabbit.oak.query.XPathToSQL2Converter.getSyntaxError(XPathToSQL2Converter.java:963)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-481) SQL2PathEscapingTest failing
[
https://issues.apache.org/jira/browse/OAK-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-481:
---
Component/s: query
SQL2PathEscapingTest failing
Key: OAK-481
URL: https://issues.apache.org/jira/browse/OAK-481
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: jcr, query
Reporter: Alex Parvulescu
Fix For: 0.13
Following the fix of OAK-295, we now have a bunch of new test failures to
look at coming from {{SQL2PathEscapingTest}}:
{{testGetChildrenNoEscaping}} Wrong hit count. expected:0 but was:2
{{testGetChildrenEscapedFull}}
{code}
java.text.ParseException: Query: select * from [nt:base] AS selector where
ISCHILDNODE(selector, ['/testroot/a b'])(*); expected: absolute path
{code}
{{testGetChildrenEscapedNode}} Wrong hit count. expected:2 but was:0
Full test trace following:
{code}
org.apache.jackrabbit.core.query.SQL2PathEscapingTest
testGetChildrenNoEscaping(org.apache.jackrabbit.core.query.SQL2PathEscapingTest)
junit.framework.AssertionFailedError: Wrong hit count. expected:0 but
was:2
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:67)
at junit.framework.Assert.assertEquals(Assert.java:199)
at
org.apache.jackrabbit.core.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:92)
at
org.apache.jackrabbit.core.query.SQL2PathEscapingTest.testGetChildrenNoEscaping(SQL2PathEscapingTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at
org.apache.jackrabbit.test.ConcurrentTestSuite.access$001(ConcurrentTestSuite.java:29)
at
org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:662)
testGetChildrenEscapedFull(org.apache.jackrabbit.core.query.SQL2PathEscapingTest)
javax.jcr.query.InvalidQueryException: java.text.ParseException: Query:
select * from [nt:base] AS selector where ISCHILDNODE(selector, ['/testroot/a
b'])(*); expected: absolute path
at
org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:126)
at
org.apache.jackrabbit.oak.jcr.query.QueryImpl.execute(QueryImpl.java:83)
at
org.apache.jackrabbit.core.query.AbstractQueryTest.executeSQL2Query(AbstractQueryTest.java:269)
at
org.apache.jackrabbit.core.query.SQL2PathEscapingTest.testGetChildrenEscapedFull(SQL2PathEscapingTest.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at
org.apache.jackrabbit.test.ConcurrentTestSuite.access$001(ConcurrentTestSuite.java:29)
at
org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source)
at
[jira] [Updated] (OAK-328) jcr:like(fn:name(), '%:content') should not match jcr:content
[
https://issues.apache.org/jira/browse/OAK-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-328:
---
Component/s: query
jcr:like(fn:name(), '%:content') should not match jcr:content
-
Key: OAK-328
URL: https://issues.apache.org/jira/browse/OAK-328
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: jcr, query
Reporter: Alex Parvulescu
Fix For: 0.15
Failing test is FnNameQueryTest#testLikeWithPrefix.
The test expects this query to not match any nodes:
{noformat}
testroot/*[@prop1 = 1 and jcr:like(fn:name(), '%:content')]
{noformat}
...which boils down to jcr:like(fn:name(), '%:content') should not match
jcr:content.
I need to look-up the specs on this one.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-321) Deref (jcr:deref) support
[
https://issues.apache.org/jira/browse/OAK-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-321:
---
Component/s: query
Deref (jcr:deref) support
-
Key: OAK-321
URL: https://issues.apache.org/jira/browse/OAK-321
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: jcr, query
Reporter: Alex Parvulescu
Fix For: 0.12
Test class DerefTest.
For now there are just parse exceptions:
{noformat}
javax.jcr.query.InvalidQueryException: java.text.ParseException: Query:
testroot/people/jcr:deref((*)@worksfor, '*'); expected: end
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-852) DescendantNodeJoinConditionTest failures
[
https://issues.apache.org/jira/browse/OAK-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-852:
---
Component/s: query
DescendantNodeJoinConditionTest failures
Key: OAK-852
URL: https://issues.apache.org/jira/browse/OAK-852
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, query
Reporter: Jukka Zitting
Priority: Minor
The {{testInnerJoin}} test failure was earlier triggered by the presumably
unrelated OAK-325, and in addition the {{testLeftOuterJoin}} test currently
fails with the MongoMK and SegmentMK.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-636) QueryIT test fails occasionally with Java7
[ https://issues.apache.org/jira/browse/OAK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-636: --- Component/s: query QueryIT test fails occasionally with Java7 -- Key: OAK-636 URL: https://issues.apache.org/jira/browse/OAK-636 Project: Jackrabbit Oak Issue Type: Bug Components: jcr, query Affects Versions: 0.6 Environment: Windows 7, Oracle JDK 1.7.0-b147 Reporter: Marcel Reutegger Priority: Minor Attachments: org.apache.jackrabbit.oak.jcr.tck.QueryIT.txt QueryIT tests fail on my machine (Win7) with Java7 4 times out of 10 runs. The same tests consistently succeed with Java6. Maven command used in oak-jcr: mvn -Dtest=QueryIT -PintegrationTesting clean test -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-948) Compatibility - Oak not generates property change event for touched properties
[ https://issues.apache.org/jira/browse/OAK-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-948. --- Resolution: Won't Fix Fix Version/s: 0.11 Resolving as won't fix as discussed Compatibility - Oak not generates property change event for touched properties --- Key: OAK-948 URL: https://issues.apache.org/jira/browse/OAK-948 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 0.8 Reporter: Chetan Mehrotra Priority: Minor Labels: compatibility, observation Fix For: 0.11 In Jackrabbit if a property is _touched_ i.e. actual property not modified but just touched it leads to propertyChange event In comparison Oak only generates propertyChange event if the property is actually modified. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-948) Compatibility - Oak not generates property change event for touched properties
[ https://issues.apache.org/jira/browse/OAK-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-948: -- Labels: compatibility observation (was: compatibility) Compatibility - Oak not generates property change event for touched properties --- Key: OAK-948 URL: https://issues.apache.org/jira/browse/OAK-948 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 0.8 Reporter: Chetan Mehrotra Priority: Minor Labels: compatibility, observation Fix For: 0.11 In Jackrabbit if a property is _touched_ i.e. actual property not modified but just touched it leads to propertyChange event In comparison Oak only generates propertyChange event if the property is actually modified. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-970) DocumentViewImportTest fails with SegmentMK
[ https://issues.apache.org/jira/browse/OAK-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-970. Resolution: Fixed the test is no longer present in the exclusion list. DocumentViewImportTest fails with SegmentMK --- Key: OAK-970 URL: https://issues.apache.org/jira/browse/OAK-970 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Marcel Reutegger Priority: Minor Attachments: org.apache.jackrabbit.oak.jcr.tck.ApiIT.txt The TCK test DocumentViewImportTest fails on SegmentMK with the following errors: testWorkspaceImportXml(org.apache.jackrabbit.test.api.DocumentViewImportTest) Time elapsed: 0.119 sec ERROR! javax.jcr.RepositoryException: OakName0001: Invalid namespace prefix: docview:docRoot and testSessionGetImportContentHandler(org.apache.jackrabbit.test.api.DocumentViewImportTest) Time elapsed: 0.144 sec ERROR! org.apache.jackrabbit.oak.api.CommitFailedException: OakName0001: Invalid namespace prefix: docview2:docRoot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1055) Occasional test failure in ObservationTest.observation()
[
https://issues.apache.org/jira/browse/OAK-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1055:
---
Labels: observation (was: )
Occasional test failure in ObservationTest.observation()
Key: OAK-1055
URL: https://issues.apache.org/jira/browse/OAK-1055
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
Assignee: Michael Dürig
Labels: observation
Fix For: 0.11
The test occasionally fails with
{code}
Failed tests:
observation[1](org.apache.jackrabbit.oak.jcr.observation.ObservationTest):
Unexpected events: [EventImpl{type=8, jcrPath='/test_node/property',
userID='oak:unknown', identifier='/test_node', info={}, date=0,
userData=null, external=true}, EventImpl{type=16,
jcrPath='/test_node/n1/p1', userID='oak:unknown',
identifier='/test_node/n1', info={}, date=0, userData=null,
external=true}, EventImpl{type=4, jcrPath='/test_node/n1/p2',
userID='oak:unknown', identifier='/test_node/n1', info={}, date=0,
userData=null, external=true}, EventImpl{type=2, jcrPath='/test_node/n3',
userID='oak:unknown', identifier='/test_node/n3', info={}, date=0,
userData=null, external=true}, EventImpl{type=8,
jcrPath='/test_node/n3/jcr:primaryType', userID='oak:unknown',
identifier='/test_node/n3', info={}, date=0, userData=null,
external=true}, EventImpl{type=8, jcrPath='/test_node/n3/p3',
userID='oak:unknown', identifier='/test_node/n3', info={}, date=0,
userData=null, external=true}, EventImpl{type=2, jcrPath='/test_node/{4}',
userID='oak:unknown', identifier='/test_node/{4}', info={}, date=0,
userData=null, external=true}, EventImpl{type=8,
jcrPath='/test_node/{4}/jcr:primaryType', userID='oak:unknown',
identifier='/test_node/{4}', info={}, date=0, userData=null,
external=true}, EventImpl{type=1, jcrPath='/test_node/n2',
userID='oak:unknown', identifier='/test_node/n2', info={}, date=0,
userData=null, external=true}, EventImpl{type=4,
jcrPath='/test_node/n2/jcr:primaryType', userID='oak:unknown',
identifier='/test_node/n2', info={}, date=0, userData=null,
external=true}, EventImpl{type=4, jcrPath='/test_node/property',
userID='oak:unknown', identifier='/test_node', info={}, date=0,
userData=null, external=true}, EventImpl{type=16,
jcrPath='/test_node/n1/p1', userID='oak:unknown',
identifier='/test_node/n1', info={}, date=0, userData=null,
external=true}, EventImpl{type=8, jcrPath='/test_node/n1/p2',
userID='oak:unknown', identifier='/test_node/n1', info={}, date=0,
userData=null, external=true}, EventImpl{type=2, jcrPath='/test_node/n2',
userID='oak:unknown', identifier='/test_node/n2', info={}, date=0,
userData=null, external=true}, EventImpl{type=8,
jcrPath='/test_node/n2/jcr:primaryType', userID='oak:unknown',
identifier='/test_node/n2', info={}, date=0, userData=null,
external=true}, EventImpl{type=1, jcrPath='/test_node/n3',
userID='oak:unknown', identifier='/test_node/n3', info={}, date=0,
userData=null, external=true}, EventImpl{type=4,
jcrPath='/test_node/n3/jcr:primaryType', userID='oak:unknown',
identifier='/test_node/n3', info={}, date=0, userData=null,
external=true}, EventImpl{type=4, jcrPath='/test_node/n3/p3',
userID='oak:unknown', identifier='/test_node/n3', info={}, date=0,
userData=null, external=true}, EventImpl{type=1, jcrPath='/test_node/{4}',
userID='oak:unknown', identifier='/test_node/{4}', info={}, date=0,
userData=null, external=true}, EventImpl{type=4,
jcrPath='/test_node/{4}/jcr:primaryType', userID='oak:unknown',
identifier='/test_node/{4}', info={}, date=0, userData=null,
external=true}]
{code}
As [noted before | http://markmail.org/message/lk3vrrcn5edib73d] having
{{external=true}} and also the event types indicate that the events are being
seen in reverse (i.e. reverse diffing of the node states involved).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-144) Implement observation
[ https://issues.apache.org/jira/browse/OAK-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-144: -- Labels: observation (was: ) Implement observation - Key: OAK-144 URL: https://issues.apache.org/jira/browse/OAK-144 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: Michael Dürig Assignee: Michael Dürig Labels: observation -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-877) Generating observation events takes too long when intermediate save calls are involved
[ https://issues.apache.org/jira/browse/OAK-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-877: -- Labels: observation (was: ) Generating observation events takes too long when intermediate save calls are involved -- Key: OAK-877 URL: https://issues.apache.org/jira/browse/OAK-877 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Michael Dürig Assignee: Michael Dürig Labels: observation Fix For: 0.9 Attachments: 1_save.png, 2.save.png, 3_save.png, OAK-877.patch Creating observation events is much more expensive when a transaction is broken down through intermediate save calls compared to only having a single save call. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-775) Implement backward compatible observation
[ https://issues.apache.org/jira/browse/OAK-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-775: -- Labels: observation (was: ) Implement backward compatible observation - Key: OAK-775 URL: https://issues.apache.org/jira/browse/OAK-775 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: Michael Dürig Assignee: Michael Dürig Labels: observation Fix For: 0.9 Attachments: OAK-775-isExternal.patch, OAK-775.patch As [discussed | http://markmail.org/message/6bqycmx6vbq7m25c] we might want look into implementing an alternative approach to observation, which trades some scalability for improved backward compatibility. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-900) Run Jackrabbit Observation tests
[ https://issues.apache.org/jira/browse/OAK-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-900: -- Labels: observation (was: ) Run Jackrabbit Observation tests Key: OAK-900 URL: https://issues.apache.org/jira/browse/OAK-900 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: Alex Parvulescu Assignee: Alex Parvulescu Labels: observation Fix For: 0.11 Similar to OAK-237, I'd like to import the existing Observation tests from Jackrabbit and run them against an Oak repository -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-675) Observation generates NPE in an existing EventListener
[
https://issues.apache.org/jira/browse/OAK-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-675:
--
Labels: observation (was: )
Observation generates NPE in an existing EventListener
--
Key: OAK-675
URL: https://issues.apache.org/jira/browse/OAK-675
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Alex Parvulescu
Assignee: Michael Dürig
Labels: observation
Fix For: 0.9
Because there is no user id passed on to the events generated by the
_ChangeProcessor_, the sling EventListener throws a bunch of NPEs when it
receives the events.
{code}
06.03.2013 11:33:13.866 *ERROR* [pool-4-thread-1]
org.apache.jackrabbit.oak.plugins.observation.ChangeProcessor Unable to
generate or send events java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at
org.apache.sling.jcr.resource.internal.JcrResourceListener.sendOsgiEvent(JcrResourceListener.java:298)
at
org.apache.sling.jcr.resource.internal.JcrResourceListener.onEvent(JcrResourceListener.java:218)
at
org.apache.jackrabbit.oak.plugins.observation.ChangeProcessor$EventGeneratingNodeStateDiff.sendEvents(ChangeProcessor.java:154)
at
org.apache.jackrabbit.oak.plugins.observation.ChangeProcessor.run(ChangeProcessor.java:117)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-1143) [scala] Repository init throws illegal cyclic reference involving class ChangeDispatcher
[
https://issues.apache.org/jira/browse/OAK-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1143:
---
Labels: observation (was: )
[scala] Repository init throws illegal cyclic reference involving class
ChangeDispatcher
--
Key: OAK-1143
URL: https://issues.apache.org/jira/browse/OAK-1143
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Alex Parvulescu
Priority: Minor
Labels: observation
I've been playing with Oak on Scala a bit and it looks like the latest
changes introduced a problem that makes Oak unusable.
Basically trying to setup a repo throws the following error:
{noformat}
OakRepository.scala:65: error: illegal cyclic reference involving class
ChangeDispatcher
[ERROR] new Oak(new SegmentNodeStore(new FileStore(new File(fname),
268435456, true)))
[ERROR] ^
[ERROR] one error found
{noformat}
I've simplified the code down to the most basic barebone repo init to make it
easier to digest [0].
This is a Scala bug, but my point is that this used to work prior to the
changedispacher changes, so I'm thinking we could move some bits around to
get it working from Scala again.
[0]
https://github.com/alexparvulescu/soak/blob/master/src/main/scala/com/pfalabs/soak/OakRepository.scala#L65
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-1133) Observation listener PLUS
[
https://issues.apache.org/jira/browse/OAK-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1133:
---
Labels: observation performance (was: performance)
Observation listener PLUS
-
Key: OAK-1133
URL: https://issues.apache.org/jira/browse/OAK-1133
Project: Jackrabbit Oak
Issue Type: New Feature
Components: commons, jcr
Reporter: Alexander Klimetschek
Labels: observation, performance
Fix For: 0.12
Oak should provide an *extended and efficient JCR observation listener*
mechanism to support common use cases not handled well by the restricted
options of the JCR observation (only base path, node types and raw events).
Those cases require listeners to register much more broadly and then filter
out their specific cases themselves, thus putting too many events into the
observation system and creating a huge overhead due to asynchronous access to
the modified JCR data to do the filtering. This easily is a big performance
bottleneck with many writes and thus many events.
Previous discussions [on the
list|http://markmail.org/message/oyq7fnfrveceemoh] and in OAK-1120, and
[latest discussion on the list|http://markmail.org/message/x2l6tv4m7bxjzqqq].
The goals should be:
* performance: handle filtering as early as possible, during the commit,
where access to the modified data is already present
* provide robust implementation for typical filtering cases
* provide an asynchronous listener mechanism as in JCR
* minimize effect on the lower levels on Oak (a visible addition in
oak-commons or oak-jcr should be enough)
* for delete events, allow filtering on the to-be-deleted data (currently not
possible in jcr listeners that run after the fact)
* ignore external cluster events by default; have an extra option if you
really want to register for external events
* if possible: design as an extension of the jcr observation to simplify
migration for existing code
* if possible: provide an intelligent listener that can work with pure JCR
(aka Jackrabbit 2) as well, by falling back to in-listener-filtering
* maybe: synchronous option using the same simple interface (instead of raw
Oak plugins itself); however, not sure if there is a benefit if they can only
read data and not change or block the session commit
Typical filtering cases:
- paths with globbing support (for example /content/foo/*/something)
- check for property values (equal, not equal, contains etc.), most
importantly
sling:resourceType in Sling apps
- allow to check properties on child nodes as well, typically jcr:content
- check for any parent/ancestor as well (e.g. change deep inside a node type
= foo structure should be triggered, even if the node with the type wasn't
modified; very important to support efficiently)
- node types (already in jcr observation)
- created/modified/deleted events, separate from move/copy
- and more... a custom filter should be possible to pass through (with
similar access as the {{Observer}})
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-949) UserQuery does not properly work for the optional everyone group
[ https://issues.apache.org/jira/browse/OAK-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-949. Resolution: Fixed Fix Version/s: 0.11 Committed revision 1541015. UserQuery does not properly work for the optional everyone group Key: OAK-949 URL: https://issues.apache.org/jira/browse/OAK-949 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela Priority: Minor Fix For: 0.11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1145) [Observation] Support for EventJournal in Oak
[ https://issues.apache.org/jira/browse/OAK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820059#comment-13820059 ] Daniel Platon commented on OAK-1145: Hi everyone, Thanks you for your insights. bq.What if the feed contains entries from last month and last year - that's an area the journal very likely won't cover any more. This won't be the case here. An incremental feed would likely go back a few days (a week, tops). bq. A query is one solution but you might also design the content structure so that it is easy to generate the feed via traversal. This is not up to me, unfortunately I will give queries a try. Up till now I used mostly JR2 and that's why I didn't consider them very much. [Observation] Support for EventJournal in Oak - Key: OAK-1145 URL: https://issues.apache.org/jira/browse/OAK-1145 Project: Jackrabbit Oak Issue Type: New Feature Components: jcr Affects Versions: 0.10 Reporter: Daniel Platon Labels: features Fix For: 0.14 Please add support for EventJournal in Oak, as it was present in Jackrabbit 2. Thank you. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1143) [scala] Repository init throws illegal cyclic reference involving class ChangeDispatcher
[
https://issues.apache.org/jira/browse/OAK-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-1143.
--
Resolution: Fixed
Fix Version/s: 0.11
yes indeed, the problems are now gone.
thanks a lot Michael!
[scala] Repository init throws illegal cyclic reference involving class
ChangeDispatcher
--
Key: OAK-1143
URL: https://issues.apache.org/jira/browse/OAK-1143
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Alex Parvulescu
Priority: Minor
Labels: observation
Fix For: 0.11
I've been playing with Oak on Scala a bit and it looks like the latest
changes introduced a problem that makes Oak unusable.
Basically trying to setup a repo throws the following error:
{noformat}
OakRepository.scala:65: error: illegal cyclic reference involving class
ChangeDispatcher
[ERROR] new Oak(new SegmentNodeStore(new FileStore(new File(fname),
268435456, true)))
[ERROR] ^
[ERROR] one error found
{noformat}
I've simplified the code down to the most basic barebone repo init to make it
easier to digest [0].
This is a Scala bug, but my point is that this used to work prior to the
changedispacher changes, so I'm thinking we could move some bits around to
get it working from Scala again.
[0]
https://github.com/alexparvulescu/soak/blob/master/src/main/scala/com/pfalabs/soak/OakRepository.scala#L65
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (OAK-910) Privilege Management: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720871#comment-13720871
]
angela edited comment on OAK-910 at 11/12/13 3:55 PM:
--
moved to
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-doc/src/site/markdown/differences_privileges.md
was (Author: anchela):
h4. 1. Characteristics of the Privilege Management Implementation
h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level
date (node types, namespaces and versions) this location is shared by all
workspaces present in the repository. The nodes and properties storing the
privilege definitions are protected by their node type definition. In addition
a specific privilege {{Validator}} and {{CommitHook}} implementations assert
the consistency of the privilege store. The built-in privileges are installed
using a dedicated implementation of the {{RepositoryInitializer}} [0].
h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that
modifications made on the OAK API directly is equally verified. Subsequently
any violation (permission, privilege consistency) is only detected at the end
of the registration process. The privilege manager itself does not perform any
validation.
h4. 2. Built-in Privilege Definitions
* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* New Privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties
Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties,
rep:alterProperties and rep:removeProperties
h4. 3. Node Type Definitions
The following privilege related built-in node types have been added in OAK 1.0.
They are used to represent built-in and custom privilege definitions in the
repository.
{code}
[rep:Privileges]
+ * (rep:Privilege) = rep:Privilege protected ABORT
- rep:next (LONG) protected multiple mandatory
[rep:Privilege]
- rep:isAbstract (BOOLEAN) protected
- rep:aggregates (NAME) protected multiple
- rep:bits (LONG) protected multiple mandatory
{code}
h4. 4. API Extensions
org.apache.jackrabbit.oak.spi.security.privilege
- {{PrivilegeBitsProvider}} : Provider implementation to read {{PrivilegeBits}}
from the repository content and map names to internal representation (and vice
versa) [2].
- {{PrivilegeBits}}: Internal representation of JCR privileges [3].
h4. 5. Configuration
* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} - returns a new instance of the
{{PrivilegeManager}} interface such as exposed by
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default
implementation is based on OAK API and can equally be used for privilege
related tasks in the OAK layer.
h4. 6. References
[0]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java
[2]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeBitsProvider.java
[3]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeBits.java
Privilege Management: Document changes wrt Jackrabbit
-
Key: OAK-910
URL: https://issues.apache.org/jira/browse/OAK-910
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, jcr
Reporter:
[jira] [Comment Edited] (OAK-909) PrincipalManagement: Document changes wrt Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13725069#comment-13725069
]
angela edited comment on OAK-909 at 11/12/13 3:54 PM:
--
moved to
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-doc/src/site/markdown/differences_principal.md
was (Author: anchela):
h4. 1. Characteristics of the Principal Management Implementation
The default implementation of the principal management API basically
corresponds to the default in Jackrabbit 2.x and is based on the user
management implementation. Note however, that as of OAK only a single principal
provider is exposed on the SPI level (used to be multiple principal providers
with the LoginModule configuration in Jackrabbit 2.x). See the configuration
section below for details
h4. 2. API Extensions
* {{PrincipalProvider}} [0]: SPI level access to principals known to the
repository which is also used by the default implementation of the
{{PrincipalManager}} interface. This interface replaces the internal
PrincipalProvider interface present in Jackrabbit 2.x. Note, that principals
from different sources can be supported by using {{CompositePrincipalProvider}}
[1] or a similar implementation that proxies different sources.
* {{AdminPrincipal}}: Marker interface to identify the principal associated
with administrative user(s) [2].
* {{EveryonePrincipal}}: built-in group principal implementation that has every
other valid principal as member [3].
* {{SystemPrincipal}}: built-in principal implementation to mark system
internal subjects [4].
h4. 3. Configuration
* {{PrincipalConfiguration}} [5]:
** {{getPrincipalManager}} - returns a new instance of
o.a.j.api.security.principal.PrincipalManager [6] (see also
{{JackrabbitSession#getPrincipalManager()}}
** {{getPrincipalProvider}} - returns a new instance of principal provider.
Note, that in contrast to Jackrabbit 2.x the system may only have one single
principal provider implementation configured. In order to combine principals
from different sources a implementation that properly handles the different
sources is required; the {{CompositePrincipalProvider}} [1] is an example that
combines multiple implementations.
h4. 4. References
[0]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalProvider.java
[1]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.java
[2]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/AdminPrincipal.java
[3]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.java
[4]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/SystemPrincipal.java
[5]
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/principal/PrincipalConfiguration.java
[6]
http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/principal/PrincipalManager.java
PrincipalManagement: Document changes wrt Jackrabbit
Key: OAK-909
URL: https://issues.apache.org/jira/browse/OAK-909
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, jcr
Reporter: angela
Assignee: angela
Fix For: 0.9
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-1105) Osgi pluggability for the TokenProvider
[ https://issues.apache.org/jira/browse/OAK-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1105. - Resolution: Fixed Fix Version/s: 0.11 i decided to move the token stuff to a separate configuration - Committed revision 1541128. Osgi pluggability for the TokenProvider --- Key: OAK-1105 URL: https://issues.apache.org/jira/browse/OAK-1105 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: Antonio Sanso Assignee: angela Priority: Minor Fix For: 0.11 Attachments: OAK-1105-patch.txt It would be nice to have Osgi pluggability for the TokenProvider as for other part of Oak. Patch to follow -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1087) TCK tests fail with SegmentMK and MongoStore
[
https://issues.apache.org/jira/browse/OAK-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-1087.
Resolution: Fixed
Fix Version/s: (was: 0.12)
0.11
Fixed in revision 1541132.
TCK tests fail with SegmentMK and MongoStore
Key: OAK-1087
URL: https://issues.apache.org/jira/browse/OAK-1087
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 0.10
Reporter: Marcel Reutegger
Assignee: Jukka Zitting
Fix For: 0.11
Looks like all tests fail to initialize the repository. E.g.:
{noformat}
testGetName(org.apache.jackrabbit.test.api.RootNodeTest) Time elapsed: 0.013
sec ERROR!
javax.jcr.RepositoryException: Failed to get Repository instance.
at
org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:72)
at
org.apache.jackrabbit.test.RepositoryHelper.getProperty(RepositoryHelper.java:152)
at
org.apache.jackrabbit.test.AbstractJCRTest.getProperty(AbstractJCRTest.java:514)
at
org.apache.jackrabbit.test.AbstractJCRTest.setUp(AbstractJCRTest.java:308)
at
org.apache.jackrabbit.test.api.RootNodeTest.setUp(RootNodeTest.java:47)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: org.apache.jackrabbit.test.RepositoryStubException:
java.lang.reflect.InvocationTargetException
at
org.apache.jackrabbit.test.RepositoryStub.getInstance(RepositoryStub.java:219)
at
org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:68)
... 29 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.jackrabbit.test.RepositoryStub.getInstance(RepositoryStub.java:217)
... 30 more
Caused by: javax.jcr.RepositoryException: java.lang.IllegalStateException:
Failed to load segment e6cd4a21-5c0e-4646-a129-446018836ce0
at
org.apache.jackrabbit.oak.jcr.OakSegmentMKRepositoryStub.init(OakSegmentMKRepositoryStub.java:77)
... 35 more
Caused by: java.lang.IllegalStateException: Failed to load segment
e6cd4a21-5c0e-4646-a129-446018836ce0
at
org.apache.jackrabbit.oak.plugins.segment.AbstractStore.readSegment(AbstractStore.java:97)
at
org.apache.jackrabbit.oak.plugins.segment.Segment.getSegment(Segment.java:150)
at
org.apache.jackrabbit.oak.plugins.segment.Record.getSegment(Record.java:96)
at
[jira] [Commented] (OAK-884) Add simple acl randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820233#comment-13820233 ] angela commented on OAK-884: just discussed with [~asanso] and he promised to provide an update for that patch... oak-run is probably not the right location (and maybe you can also fix the indention ;-) Add simple acl randomized test -- Key: OAK-884 URL: https://issues.apache.org/jira/browse/OAK-884 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Antonio Sanso Assignee: angela Fix For: 0.13 Attachments: OAK-884-patch.txt Taking as example org.apache.jackrabbit.oak.plugins.mongomk.RandomizedTest it would be nice to have some randomized test also for the ACL evaluation. The logic for the upcoming test patch is to add/remove randomly read permission entry and traverse the tree evaluation the read permission. The result is compared with a Jackrabbit (that is considered as a functional gold implementation) outcome and it is expected to match. Should not match then we have a problem... Patch to follow -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1048) Unify node type management in the query index impls
[ https://issues.apache.org/jira/browse/OAK-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-1048. Resolution: Fixed Fix Version/s: (was: 0.14) 0.11 Done partially in revision 1536366 with the new TypePredicate class. However, in the higher level code (SelectorImpl, etc.) the node type information is used in more complex ways (need to be able to access subtype names for example to construct a Lucene query) that become tricky to do efficiently in a generic utility class. Thus I'll leave the higher level code as-is and resolve this as Fixed based on revision 1536366. Unify node type management in the query index impls --- Key: OAK-1048 URL: https://issues.apache.org/jira/browse/OAK-1048 Project: Jackrabbit Oak Issue Type: Improvement Components: core, query Reporter: Alex Parvulescu Assignee: Jukka Zitting Fix For: 0.11 Currently the query index implementations that are node type aware access this info directly from the NodeState by reading the child nodes. This is fragile (the node type managemet impl may change structure and break the tests), and also may hide some access patterns which are node-type related behind normal _getChildNode_ calls. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-801) Add Javadoc to JsonObject.create(JsopTokenizer)
[
https://issues.apache.org/jira/browse/OAK-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-801.
---
Resolution: Fixed
Fix Version/s: 0.11
Assignee: Jukka Zitting
Done in revision 1541229.
Add Javadoc to JsonObject.create(JsopTokenizer)
---
Key: OAK-801
URL: https://issues.apache.org/jira/browse/OAK-801
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Affects Versions: 0.7
Reporter: Lukas Eder
Assignee: Jukka Zitting
Priority: Trivial
Fix For: 0.11
When browsing code, I was surprised to find a factory method
JsonObject.create(JsopTokenizer), which operates on a tokenizer that is
expected to be in some post-initialisation state. I.e. the following doesn't
work:
{code}
JsonObject.create(new JsopTokenizer({}));
{code}
This does:
{code}
JsonObject.create(new JsopTokenizer(}));
{code}
I understand that the goal of this method is to be used in larger JSON
parsing contexts, where JsopTokenizer has already consumed a '{'. Since
JsonObject is public and OSGi-exported, I think this method deserves at least
some Javadoc.
It might be better, of course, to provide a more predictable / reusable API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-741) Better toString() methods
[ https://issues.apache.org/jira/browse/OAK-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-741. --- Resolution: Fixed Fix Version/s: 0.11 I think we can mark this as fixed as most of the key classes already have toString() methods. Better toString() methods - Key: OAK-741 URL: https://issues.apache.org/jira/browse/OAK-741 Project: Jackrabbit Oak Issue Type: Improvement Components: core, jcr Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 0.11 When debugging, it would be nice if more of our key classes provided useful state information through their toString() methods. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-776) NodeState convenience accessors
[
https://issues.apache.org/jira/browse/OAK-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-776.
---
Resolution: Fixed
Fix Version/s: (was: 0.13)
0.11
The following convenience accessors are now available:
* {{getBoolean()}}
* {{getLong()}}
* {{getString()}}
* {{getName()}}
* {{getNames()}}
They seem to cover by far the most common access patterns so resolving this as
Fixed.
NodeState convenience accessors
---
Key: OAK-776
URL: https://issues.apache.org/jira/browse/OAK-776
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Fix For: 0.11
One of the original goals in designing the NodeState interface was to avoid
too many convenience accessors to keep the interface simple and easily to
decorate with things like the SecureNodeState wrapper. Since then convenience
code like type-specific property value accessors have been added in various
places as ad-hoc static utility methods.
Now that the overall NodeState design is mostly fixed, the set of NodeState
implementations mostly known and we have a good idea of the common NodeState
access patterns, I think it would be useful to add various convenience
methods like {{hasProperty(String)}} or {{getBoolean(String)}} that allow us
to both simplify commonly occurring client code and further optimize the
SegmentNodeState class without requiring it to cache fully loaded
PropertyState instances in memory.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-76) Initial content in oak-run
[
https://issues.apache.org/jira/browse/OAK-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-76.
--
Resolution: Fixed
Fix Version/s: 0.11
The {{oak-http}} README describes how to interact with the web interface
exposed by {{oak-run}}. I think that's enough to resolve this as Fixed.
Initial content in oak-run
--
Key: OAK-76
URL: https://issues.apache.org/jira/browse/OAK-76
Project: Jackrabbit Oak
Issue Type: Improvement
Components: run
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Priority: Minor
Fix For: 0.11
It would be nice if the oak-run jar, when executed without arguments (i.e.
with an in-memory test repository), started up with some basic test content
so one wouldn't need to figure out how to upload some before seeing anything
interesting.
Also, accessing oak-run shouldn't require any credentials until we have
actual authentication code in place.
And finally there should be some basic documentation in oak-run/README.md
about how to use the tool.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-636) QueryIT test fails occasionally with Java7
[ https://issues.apache.org/jira/browse/OAK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved OAK-636. --- Resolution: Cannot Reproduce AFAICT these don't occur anymore. At least not on my laptop with the same configuration. Resolving as Cannot Reproduce. QueryIT test fails occasionally with Java7 -- Key: OAK-636 URL: https://issues.apache.org/jira/browse/OAK-636 Project: Jackrabbit Oak Issue Type: Bug Components: jcr, query Affects Versions: 0.6 Environment: Windows 7, Oracle JDK 1.7.0-b147 Reporter: Marcel Reutegger Priority: Minor Attachments: org.apache.jackrabbit.oak.jcr.tck.QueryIT.txt QueryIT tests fail on my machine (Win7) with Java7 4 times out of 10 runs. The same tests consistently succeed with Java6. Maven command used in oak-jcr: mvn -Dtest=QueryIT -PintegrationTesting clean test -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1169) Update Guava to version 15.0
[ https://issues.apache.org/jira/browse/OAK-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820466#comment-13820466 ] Jukka Zitting commented on OAK-1169: +1 Update Guava to version 15.0 Key: OAK-1169 URL: https://issues.apache.org/jira/browse/OAK-1169 Project: Jackrabbit Oak Issue Type: Task Affects Versions: 0.10 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Update the Guava library version to 15.0 [1]. I would like to use the new TreeTraversor [2] for OAK-1156. [1] https://code.google.com/p/guava-libraries/wiki/Release15 [2] http://docs.guava-libraries.googlecode.com/git-history/v15.0/javadoc/com/google/common/collect/TreeTraverser.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1171) Query fails unexpectedly when property conversion is not possible
Alexander Klimetschek created OAK-1171:
--
Summary: Query fails unexpectedly when property conversion is not
possible
Key: OAK-1171
URL: https://issues.apache.org/jira/browse/OAK-1171
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr, query
Reporter: Alexander Klimetschek
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = foo]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}} and
fail the query.
Jackrabbit 2 works well here and simply does not include a match for that node
in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1 as
described in §3.6.4 Property Type Conversion. If the type conversion fails, the
query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1171) Query fails unexpectedly when property conversion is not possible
[
https://issues.apache.org/jira/browse/OAK-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820899#comment-13820899
]
Alexander Klimetschek commented on OAK-1171:
OAK-1076 might be related. It refers to range queries, not the equality
operator, but the issue might be the same.
Query fails unexpectedly when property conversion is not possible
-
Key: OAK-1171
URL: https://issues.apache.org/jira/browse/OAK-1171
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr, query
Reporter: Alexander Klimetschek
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = foo]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}}
and fail the query.
Jackrabbit 2 works well here and simply does not include a match for that
node in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1
as described in §3.6.4 Property Type Conversion. If the type conversion
fails, the query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1171) Query fails unexpectedly when property conversion is not possible
[
https://issues.apache.org/jira/browse/OAK-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820905#comment-13820905
]
Alexander Klimetschek commented on OAK-1171:
The simplest solution might be to catch that exception somewhere inside
{{AstElement#convertValueToType}} or {{ComparisonImpl#evaluate}}, AFAICS.
Query fails unexpectedly when property conversion is not possible
-
Key: OAK-1171
URL: https://issues.apache.org/jira/browse/OAK-1171
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr, query
Reporter: Alexander Klimetschek
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = foo]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}}
and fail the query.
Jackrabbit 2 works well here and simply does not include a match for that
node in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1
as described in §3.6.4 Property Type Conversion. If the type conversion
fails, the query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-1171) Query fails unexpectedly when property conversion is not possible
[
https://issues.apache.org/jira/browse/OAK-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-1171:
---
Description:
A simple xpath query for a string property doesn't work when there is a long
(or other inconvertible) property under the same name anywhere in the
repository.
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = foo]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}} and
fail the query.
Jackrabbit 2 works well here and simply does not include a match for that node
in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1 as
described in §3.6.4 Property Type Conversion. If the type conversion fails, the
query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
was:
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = foo]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}} and
fail the query.
Jackrabbit 2 works well here and simply does not include a match for that node
in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1 as
described in §3.6.4 Property Type Conversion. If the type conversion fails, the
query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
Query fails unexpectedly when property conversion is not possible
-
Key: OAK-1171
URL: https://issues.apache.org/jira/browse/OAK-1171
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr, query
Reporter: Alexander Klimetschek
A simple xpath query for a string property doesn't work when there is a long
(or other inconvertible) property under the same name anywhere in the
repository.
To reproduce:
* Create a {{LONG}} property: {{/test/@property = 1}}
* Run this query: {{//*\[property = foo]}}
This will throw a NumberFormatException at
{{o.a.j.o.plugins.value.Conversions$Converter.toLong(Conversions.java:80)}}
and fail the query.
Jackrabbit 2 works well here and simply does not include a match for that
node in the result. While I can see that Oak seems to implement the [JCR 2.0
spec|http://www.day.com/specs/jcr/2.0/6_Query.html#6.7.16%20Comparison] here:
{quote}
If operand1 and operand2 evaluate to values of different property types, the
value of operand2 is converted to the property type of the value of operand1
as described in §3.6.4 Property Type Conversion. If the type conversion
fails, the query is _invalid_.
{quote}
... I don't think this makes any sense. If conversion does not work, this is
simply not a match, but it must not break the query.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1169) Update Guava to version 15.0
[ https://issues.apache.org/jira/browse/OAK-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820944#comment-13820944 ] Chetan Mehrotra commented on OAK-1169: -- Updated the version in rev r1541385 Update Guava to version 15.0 Key: OAK-1169 URL: https://issues.apache.org/jira/browse/OAK-1169 Project: Jackrabbit Oak Issue Type: Task Affects Versions: 0.10 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Update the Guava library version to 15.0 [1]. I would like to use the new TreeTraversor [2] for OAK-1156. [1] https://code.google.com/p/guava-libraries/wiki/Release15 [2] http://docs.guava-libraries.googlecode.com/git-history/v15.0/javadoc/com/google/common/collect/TreeTraverser.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1169) Update Guava to version 15.0
[ https://issues.apache.org/jira/browse/OAK-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-1169. -- Resolution: Fixed Fix Version/s: 0.11 Update Guava to version 15.0 Key: OAK-1169 URL: https://issues.apache.org/jira/browse/OAK-1169 Project: Jackrabbit Oak Issue Type: Task Affects Versions: 0.10 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 0.11 Update the Guava library version to 15.0 [1]. I would like to use the new TreeTraversor [2] for OAK-1156. [1] https://code.google.com/p/guava-libraries/wiki/Release15 [2] http://docs.guava-libraries.googlecode.com/git-history/v15.0/javadoc/com/google/common/collect/TreeTraverser.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1172) AbstractTree.getChildrenCount() not very performant due to INTERNAL_NODE_NAMES
Tobias Bocanegra created OAK-1172:
-
Summary: AbstractTree.getChildrenCount() not very performant due
to INTERNAL_NODE_NAMES
Key: OAK-1172
URL: https://issues.apache.org/jira/browse/OAK-1172
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Tobias Bocanegra
the AbstractTree.getChildrenCount() does unnecessary checks for hidden names:
{code}
long count = nodeBuilder.getChildNodeCount(max);
for (String name : INTERNAL_NODE_NAMES) {
if (nodeBuilder.hasChildNode(name)) {
count--;
}
}
{code}
this is not optimal, especially because the nodebuilder creates child builders:
{code}
public boolean hasChildNode(@Nonnull String name) {
return getChildNode(name).exists();
}
{code}
Suggest: to extend the NodeBuilder.getChildNodeCount() method to accept an
additional flag if to include hidden nodes or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-1173) NPE if TreePermissionImpl if tree does not have a primary type
[
https://issues.apache.org/jira/browse/OAK-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-1173:
--
Priority: Blocker (was: Major)
NPE if TreePermissionImpl if tree does not have a primary type
--
Key: OAK-1173
URL: https://issues.apache.org/jira/browse/OAK-1173
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Tobias Bocanegra
Priority: Blocker
NPE If a tree given to CompiledPermissionImpl.getTreePermission() does not
have a primary type, e.g. for a hidden oak node:
{noformat}
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.getTreePermission(CompiledPermissionImpl.java:160)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl$TreePermissionImpl.getChildPermission(CompiledPermissionImpl.java:443)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:352)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.exists(SecureNodeBuilder.java:129)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.hasChildNode(SecureNodeBuilder.java:271)
at
org.apache.jackrabbit.oak.core.AbstractTree.getChildrenCount(AbstractTree.java:248)
{noformat}
The tree passed here to get the children count is:
{{/jcr:system/jcr:versionStorage}} and the child node not having a primary
type is {{:index}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1173) NPE if TreePermissionImpl if tree does not have a primary type
[
https://issues.apache.org/jira/browse/OAK-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821022#comment-13821022
]
Tobias Bocanegra commented on OAK-1173:
---
Potential Test Case:
{code}
class
org.apache.jackrabbit.oak.security.authorization.permission.TreePermissionImplTest
...
@Test
public void testCanReadHiddenNode() throws Exception {
// ensure that :index exists
Tree adminIndex = root.getTree(/jcr:system/jcr:versionStorage/:index);
assertTrue(adminIndex.exists());
ContentSession session = createTestSession();
Root root = session.getLatestRoot();
Tree vs = root.getTree(/jcr:system/jcr:versionStorage);
Tree index = vs.getChild(:index);
assertTrue(index.exists());
session.close();
}
{code}
NPE if TreePermissionImpl if tree does not have a primary type
--
Key: OAK-1173
URL: https://issues.apache.org/jira/browse/OAK-1173
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Tobias Bocanegra
NPE If a tree given to CompiledPermissionImpl.getTreePermission() does not
have a primary type, e.g. for a hidden oak node:
{noformat}
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.getTreePermission(CompiledPermissionImpl.java:160)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl$TreePermissionImpl.getChildPermission(CompiledPermissionImpl.java:443)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:352)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.exists(SecureNodeBuilder.java:129)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.hasChildNode(SecureNodeBuilder.java:271)
at
org.apache.jackrabbit.oak.core.AbstractTree.getChildrenCount(AbstractTree.java:248)
{noformat}
The tree passed here to get the children count is:
{{/jcr:system/jcr:versionStorage}} and the child node not having a primary
type is {{:index}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1173) NPE if TreePermissionImpl if tree does not have a primary type
[
https://issues.apache.org/jira/browse/OAK-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821024#comment-13821024
]
Tobias Bocanegra commented on OAK-1173:
---
also see OAK-1172 which shows that getChildNodeCount() does extra checks for
hidden child nodes
NPE if TreePermissionImpl if tree does not have a primary type
--
Key: OAK-1173
URL: https://issues.apache.org/jira/browse/OAK-1173
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Tobias Bocanegra
Priority: Blocker
NPE If a tree given to CompiledPermissionImpl.getTreePermission() does not
have a primary type, e.g. for a hidden oak node:
{noformat}
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl.getTreePermission(CompiledPermissionImpl.java:160)
at
org.apache.jackrabbit.oak.security.authorization.permission.CompiledPermissionImpl$TreePermissionImpl.getChildPermission(CompiledPermissionImpl.java:443)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.getTreePermission(SecureNodeBuilder.java:352)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.exists(SecureNodeBuilder.java:129)
at
org.apache.jackrabbit.oak.core.SecureNodeBuilder.hasChildNode(SecureNodeBuilder.java:271)
at
org.apache.jackrabbit.oak.core.AbstractTree.getChildrenCount(AbstractTree.java:248)
{noformat}
The tree passed here to get the children count is:
{{/jcr:system/jcr:versionStorage}} and the child node not having a primary
type is {{:index}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (OAK-482) Group members stored in a rep:members tree
[ https://issues.apache.org/jira/browse/OAK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated OAK-482: - Remaining Estimate: 168h Original Estimate: 168h Group members stored in a rep:members tree -- Key: OAK-482 URL: https://issues.apache.org/jira/browse/OAK-482 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela Assignee: Tobias Bocanegra Fix For: 0.13 Original Estimate: 168h Remaining Estimate: 168h storing group members in a dedicated rep:members tree is currently not yet implemented. - jr 2.x node type definition allows SNS which are not supported in oak - jr 2.x node type definition stores members in residual properties, which up to now doesn't allow to use a specific property index. - the jr 2.x implementation is rather cumbersome as it doesn't allow to change the configuration later on such that existing groups can benefit from the config change. - the node names in the tree structure would rely on userId being equal to the principal name, which is not mandated. for a new implementation in oak i see the following variants to provide this feature: h6. variant 1: - drop SNS - change member-property to a multivalue rep:members property in the node hierarchy - same index as for non-tree implementation - config change will result in the member-tree to be created also for existing groups. - even if member-tree option is enabled the members are stored in the default mv property and just have a tree structured added if required based on the config option. - adjust xml import of user content accordingly pros: - dedicated property index for rep:members property defined by rep:Members works out of the box - performance of membership lookup. - fixing SNS definition - fixing confusion of uid with principalname cons: - not backwards compatible out of the box - updating membership might not be efficient - we need to add backwards compatible behavior when reading and querying existing membership information or provide an upgrade path that converts 'old' structure to the new one upon repo upgrade h6. variant 2: - rebuild use same logic as in JR2.x to build tree structure but include fixing the principalName/uid issue. pros: - backwards compatible (no upgrade path required) - most probably changing membership of a group was more efficient cons: - efficient lookup of membership doesn't work (AFAIK the property index is limited to named properties). thus we probably need to adjust the query/index logic such that a property index can be created for residual properties defined by the rep:Members node type - SNS problem not addressed - might cause failure upon upgrade -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-516) Create LdapLoginModule based on ExternalLoginModule
[ https://issues.apache.org/jira/browse/OAK-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated OAK-516: - Remaining Estimate: 168h Original Estimate: 168h Create LdapLoginModule based on ExternalLoginModule --- Key: OAK-516 URL: https://issues.apache.org/jira/browse/OAK-516 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Manfred Baedke Assignee: Tobias Bocanegra Fix For: 0.13 Attachments: LdapLoginModule.patch, LdapLoginTests.patch Original Estimate: 168h Remaining Estimate: 168h An LdapLoginModule is a natural candidate for a proof of concept of the ExternalLoginModule framework. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-516) Create LdapLoginModule based on ExternalLoginModule
[ https://issues.apache.org/jira/browse/OAK-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated OAK-516: - Fix Version/s: 0.13 Create LdapLoginModule based on ExternalLoginModule --- Key: OAK-516 URL: https://issues.apache.org/jira/browse/OAK-516 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Manfred Baedke Assignee: Tobias Bocanegra Fix For: 0.13 Attachments: LdapLoginModule.patch, LdapLoginTests.patch Original Estimate: 168h Remaining Estimate: 168h An LdapLoginModule is a natural candidate for a proof of concept of the ExternalLoginModule framework. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1138) Implement global per principal permission entry cache
[ https://issues.apache.org/jira/browse/OAK-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821028#comment-13821028 ] Tobias Bocanegra commented on OAK-1138: --- basic cache implemented, but only for the Every Implement global per principal permission entry cache - Key: OAK-1138 URL: https://issues.apache.org/jira/browse/OAK-1138 Project: Jackrabbit Oak Issue Type: Sub-task Components: security Affects Versions: 0.10 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Priority: Minor Fix For: 0.12 In order to speedup ACL evaluation, we need some sort of cache that can hold the pre-computed access control permission entries. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1138) Implement global per principal permission entry cache
[ https://issues.apache.org/jira/browse/OAK-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated OAK-1138: -- Remaining Estimate: 24h Original Estimate: 24h Implement global per principal permission entry cache - Key: OAK-1138 URL: https://issues.apache.org/jira/browse/OAK-1138 Project: Jackrabbit Oak Issue Type: Sub-task Components: security Affects Versions: 0.10 Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Priority: Minor Fix For: 0.12 Original Estimate: 24h Remaining Estimate: 24h In order to speedup ACL evaluation, we need some sort of cache that can hold the pre-computed access control permission entries. -- This message was sent by Atlassian JIRA (v6.1#6144)
