[jira] [Resolved] (OAK-521) Configurable AuthorizableAction(s)
[ https://issues.apache.org/jira/browse/OAK-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-521. Resolution: Fixed Configurable AuthorizableAction(s) -- Key: OAK-521 URL: https://issues.apache.org/jira/browse/OAK-521 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela subtask to address a remaining TODO with respect to configuration of authorizable actions such that it's extensible and pluggable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-992) NPE when running FlatTreeWithAceForSamePrincipalTest on MongoMK
[
https://issues.apache.org/jira/browse/OAK-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-992.
--
Resolution: Fixed
Fix Version/s: 0.9
Fixed in http://svn.apache.org/r1522482
NPE when running FlatTreeWithAceForSamePrincipalTest on MongoMK
---
Key: OAK-992
URL: https://issues.apache.org/jira/browse/OAK-992
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, mongomk
Affects Versions: 0.8
Reporter: Michael Dürig
Assignee: Marcel Reutegger
Fix For: 0.9
Running
{code}
benchmark FlatTreeWithAceForSamePrincipalTest Oak-Mongo
{code}
results in a NPE [1] after a couple of minutes.
My initial analysis showed that {{MicroKernel.getNodes()}} returns {{null}}
in {{KernelNodeState.init()}}. The requested revision was
{{br140e35028e6-0-1}}, AFAICS a branch revision that doesn't exist any more.
Looking at the base state in {{KernelNodeStoreBranch.InMemory.merge()}} a
couple of stack frames below I found the following:
{code}
base = /@r140e350df05-0-1 children: 5 id: /@r140e350df05-0-1 ...
base.getChildNode(a) = /a@r140e350df05-0-1 children: 9223372036854775807
id: /a@r140e350df05-0-1 ...
base.getChildNode(a).getChildNode(node9285) =
/a/node9285@br140e35028e6-0-1 children: 1 id: /a/node9285@r140e34fdff7-0-1 ...
{code}
Obviously obtaining child {{node9285}} from {{/a}} switches from a trunk
revision to a branch revision. This look suspicious.
[1]
{code}
java.lang.NullPointerException
at
org.apache.jackrabbit.mk.json.JsopTokenizer.init(JsopTokenizer.java:41)
at
org.apache.jackrabbit.mk.json.JsopTokenizer.init(JsopTokenizer.java:47)
at
org.apache.jackrabbit.oak.kernel.KernelNodeState.init(KernelNodeState.java:160)
at
org.apache.jackrabbit.oak.kernel.KernelNodeState.getProperty(KernelNodeState.java:251)
at
org.apache.jackrabbit.oak.spi.state.AbstractNodeState.getName(AbstractNodeState.java:88)
at
org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.isOfMatchingType(PropertyIndexEditor.java:165)
at
org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.enter(PropertyIndexEditor.java:189)
at
org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:58)
at
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeDeleted(EditorDiff.java:141)
at
org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstBaseState(EmptyNodeState.java:139)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeDeleted(EditorDiff.java:141)
at
org.apache.jackrabbit.oak.plugins.memory.EmptyNodeState.compareAgainstBaseState(EmptyNodeState.java:139)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeDeleted(EditorDiff.java:141)
at
org.apache.jackrabbit.oak.plugins.memory.ModifiedNodeState.compareAgainstBaseState(ModifiedNodeState.java:380)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52)
at
org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:50)
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:59)
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:59)
at
org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch$InMemory.merge(KernelNodeStoreBranch.java:287)
at
org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.merge(KernelNodeStoreBranch.java:136)
at
org.apache.jackrabbit.oak.core.AbstractRoot$2.run(AbstractRoot.java:245)
at
org.apache.jackrabbit.oak.core.AbstractRoot$2.run(AbstractRoot.java:241)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at
org.apache.jackrabbit.oak.core.AbstractRoot.commit(AbstractRoot.java:240)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:281)
at
org.apache.jackrabbit.oak.jcr.SessionImpl$8.perform(SessionImpl.java:394)
at
org.apache.jackrabbit.oak.jcr.SessionImpl$8.perform(SessionImpl.java:391)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:117)
at
org.apache.jackrabbit.oak.jcr.SessionImpl.perform(SessionImpl.java:117)
at
[jira] [Created] (OAK-1013) Node.addNode(name) different behavior from JR if NodeType resolves to an abstract
Christan Keller created OAK-1013: Summary: Node.addNode(name) different behavior from JR if NodeType resolves to an abstract Key: OAK-1013 URL: https://issues.apache.org/jira/browse/OAK-1013 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 0.8 Reporter: Christan Keller Priority: Minor In Jackrabbit, if you used node.addNode(name) and the NodeType resolved to an abstract like nt:base Jackrabbit still persisted the new Node. In Oak a ConstraintViolationException is thrown. While the Oak behavior is fully Spec complient, it still may be a migration issue for JR users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-1013) Node.addNode(name) different behavior from JR if NodeType resolves to an abstract
[ https://issues.apache.org/jira/browse/OAK-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christan Keller updated OAK-1013: - Attachment: Issue.java Simple test-case showing the issue Node.addNode(name) different behavior from JR if NodeType resolves to an abstract - Key: OAK-1013 URL: https://issues.apache.org/jira/browse/OAK-1013 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 0.8 Reporter: Christan Keller Priority: Minor Attachments: Issue.java In Jackrabbit, if you used node.addNode(name) and the NodeType resolved to an abstract like nt:base Jackrabbit still persisted the new Node. In Oak a ConstraintViolationException is thrown. While the Oak behavior is fully Spec complient, it still may be a migration issue for JR users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-1013) Node.addNode(name) different behavior from JR if NodeType resolves to an abstract
[ https://issues.apache.org/jira/browse/OAK-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765348#comment-13765348 ] Michael Dürig commented on OAK-1013: Thanks for the test case. I committed a slightly edited version at r1522532 Node.addNode(name) different behavior from JR if NodeType resolves to an abstract - Key: OAK-1013 URL: https://issues.apache.org/jira/browse/OAK-1013 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 0.8 Reporter: Christan Keller Priority: Minor Attachments: Issue.java In Jackrabbit, if you used node.addNode(name) and the NodeType resolved to an abstract like nt:base Jackrabbit still persisted the new Node. In Oak a ConstraintViolationException is thrown. While the Oak behavior is fully Spec complient, it still may be a migration issue for JR users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-1014) Allow customization of repository descriptors
Chetan Mehrotra created OAK-1014: Summary: Allow customization of repository descriptors Key: OAK-1014 URL: https://issues.apache.org/jira/browse/OAK-1014 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Instead of hardcoding descriptor instantiation in RepositoryImpl, the RepositoryImpl class should use a protected method to determine descriptor for current repository so that subclasses can more easily customize the descriptor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-1014) Allow customization of repository descriptors
[
https://issues.apache.org/jira/browse/OAK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765359#comment-13765359
]
Chetan Mehrotra commented on OAK-1014:
--
Added a protected method {{determineDescriptors}} for determine the descriptor.
Sub classes can override it to customze it
http://svn.apache.org/r1522536
Allow customization of repository descriptors
-
Key: OAK-1014
URL: https://issues.apache.org/jira/browse/OAK-1014
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Instead of hardcoding descriptor instantiation in RepositoryImpl, the
RepositoryImpl class should use a protected method to determine descriptor
for current repository so that subclasses can more easily customize the
descriptor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-1014) Allow customization of repository descriptors
[ https://issues.apache.org/jira/browse/OAK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-1014. -- Resolution: Fixed Fix Version/s: 0.9 Allow customization of repository descriptors - Key: OAK-1014 URL: https://issues.apache.org/jira/browse/OAK-1014 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: 0.9 Instead of hardcoding descriptor instantiation in RepositoryImpl, the RepositoryImpl class should use a protected method to determine descriptor for current repository so that subclasses can more easily customize the descriptor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-1015) Optimise path parsing
[
https://issues.apache.org/jira/browse/OAK-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-1015:
---
Assignee: Michael Dürig
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
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-1015) Optimise path parsing
[
https://issues.apache.org/jira/browse/OAK-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765477#comment-13765477
]
Michael Dürig commented on OAK-1015:
Revision 1522593 gets us back performance numbers comparable with those of
Jackrabbit 2:
{code}
Apache Jackrabbit Oak
# ReadPropertyTest min 10% 50% 90% max N
Jackrabbit 4 5 5 6 14 11287
Oak-Tar5 6 6 7 129455
{code}
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
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-1015) Optimise path parsing
[
https://issues.apache.org/jira/browse/OAK-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-1015.
Resolution: Fixed
Fix Version/s: 0.9
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
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-1008) Query parser splits token: FulltextQueryTest#testPredefinedEntityReference
[ https://issues.apache.org/jira/browse/OAK-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu resolved OAK-1008. -- Resolution: Fixed Fix Version/s: 0.9 Assignee: Alex Parvulescu fixed with http://svn.apache.org/r1522616 Query parser splits token: FulltextQueryTest#testPredefinedEntityReference -- Key: OAK-1008 URL: https://issues.apache.org/jira/browse/OAK-1008 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, oak-lucene, query Reporter: Alex Parvulescu Assignee: Alex Parvulescu Priority: Minor Fix For: 0.9 Attachments: OAK-1008.patch After OAK-1007, there'a new test failure _FulltextQueryTest#testPredefinedEntityReference_, because the input full-text token 'maxmoritz' in split into 2 full-text tokens 'max' and 'moritz' and passed to the full-text index as a list of tokens. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-528) Support configurable/pluggable restrictions
[ https://issues.apache.org/jira/browse/OAK-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-528. Resolution: Fixed Support configurable/pluggable restrictions --- Key: OAK-528 URL: https://issues.apache.org/jira/browse/OAK-528 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela apart from the built-in restrictions (rep:glob, possible a regexp matching, possible nt-matching) it would be desirable to allow for easy deployment of additional restrictions. in a first step i added a RestrictionProvider interface to the spi authorization package that is intended to be used both for JCR ac-editing as well as for the ac-evaluation inside oak-core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
