[jira] [Commented] (OAK-869) Runtime exception while adding node
[ https://issues.apache.org/jira/browse/OAK-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821386#comment-13821386 ] angela commented on OAK-869: adding link to OAK_1178 as discussed during the oak meeting. Runtime exception while adding node --- Key: OAK-869 URL: https://issues.apache.org/jira/browse/OAK-869 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Antonio Sanso Assignee: Jukka Zitting Fix For: 0.12 Attachments: AddChildTest.java Trying to add a node where the user has not read permission ends up in a runtime exception java.lang.IllegalStateException: This tree does not exist at com.google.common.base.Preconditions.checkState(Preconditions.java:149) at org.apache.jackrabbit.oak.core.TreeImpl.checkExists(TreeImpl.java:453) at org.apache.jackrabbit.oak.core.TreeImpl.setProperty(TreeImpl.java:347) at org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.internalAddChild(NodeDelegate.java:508) at org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.addChild(NodeDelegate.java:462) at org.apache.jackrabbit.oak.jcr.NodeImpl$5.perform(NodeImpl.java:256) at org.apache.jackrabbit.oak.jcr.NodeImpl$5.perform(NodeImpl.java:1) at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:97) at org.apache.jackrabbit.oak.jcr.ItemImpl.perform(ItemImpl.java:95) at org.apache.jackrabbit.oak.jcr.NodeImpl.addNode(NodeImpl.java:217) at org.apache.jackrabbit.oak.jcr.NodeImpl.addNode(NodeImpl.java:203) at org.apache.jackrabbit.oak.benchmark.AddChildTest.runTest(AddChildTest.java:71) at org.apache.jackrabbit.oak.benchmark.AbstractTest.execute(AbstractTest.java:146) at org.apache.jackrabbit.oak.benchmark.AddChildTest.execute(AddChildTest.java:1) at org.apache.jackrabbit.oak.benchmark.AbstractTest.runTest(AbstractTest.java:115) at org.apache.jackrabbit.oak.benchmark.AbstractTest.run(AbstractTest.java:84) at org.apache.jackrabbit.oak.benchmark.AddChildTest.run(AddChildTest.java:1) at org.apache.jackrabbit.oak.benchmark.BenchmarkRunner.main(BenchmarkRunner.java:114) It would be better to have a checked excpetion instead e.g. javax.jcr.AccessDeniedException I will attach test to reproduce the issue -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1178) MutableTree#isNew: replace implementation by NodeBuilder#isNew
[ https://issues.apache.org/jira/browse/OAK-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1178: Assignee: Jukka Zitting MutableTree#isNew: replace implementation by NodeBuilder#isNew --- Key: OAK-1178 URL: https://issues.apache.org/jira/browse/OAK-1178 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Assignee: Jukka Zitting Fix For: 0.12 Attachments: OAK-1178.patch Similar to the issue described in OAK-1177 we may consider replacing the implementation of MutableTree#isNew by the corresponding call on the NodeBuilder. See also OAK-947. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1178) MutableTree#isNew: replace implementation by NodeBuilder#isNew
[ https://issues.apache.org/jira/browse/OAK-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1178: Fix Version/s: 0.12 MutableTree#isNew: replace implementation by NodeBuilder#isNew --- Key: OAK-1178 URL: https://issues.apache.org/jira/browse/OAK-1178 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Assignee: Jukka Zitting Fix For: 0.12 Attachments: OAK-1178.patch Similar to the issue described in OAK-1177 we may consider replacing the implementation of MutableTree#isNew by the corresponding call on the NodeBuilder. See also OAK-947. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-710) PermissionValidator: Proper permission evaluation for moving/renaming nodes
[ https://issues.apache.org/jira/browse/OAK-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-710: -- Assignee: angela PermissionValidator: Proper permission evaluation for moving/renaming nodes --- Key: OAK-710 URL: https://issues.apache.org/jira/browse/OAK-710 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela Assignee: angela Fix For: 0.12 In jr-core renaming/moving nodes just this just requires MODIFY_CHILD_NODE_COLLECTION permission instead of remove + add node. However, the Validator interface currently doesn't allow for easy detection of move/rename operations. For backwards compatibility it was desirable to find a solution for this open issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1175) Security Concerns wrt Index Definitions
[ https://issues.apache.org/jira/browse/OAK-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1175: Description: see http://markmail.org/message/5ivmvhi7jbuo3jp6 for the initial request for discussion. biggest pain points from a security perspective: - missing protection or concept for protection in a default setup - location of the index definitions - node types of the nodes associated with index definitions and index content was: see http://markmail.org/message/5ivmvhi7jbuo3jp6 for the initial request for discussion. biggest pain points from a security perspective: - missing protection or concept for protection in a default setup - location of the index definitions - node types of the nodes associated with index definitions Security Concerns wrt Index Definitions --- Key: OAK-1175 URL: https://issues.apache.org/jira/browse/OAK-1175 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Priority: Critical Labels: security Fix For: 0.14 see http://markmail.org/message/5ivmvhi7jbuo3jp6 for the initial request for discussion. biggest pain points from a security perspective: - missing protection or concept for protection in a default setup - location of the index definitions - node types of the nodes associated with index definitions and index content -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1181) Review node type definition for oak:queryIndexDefinition
angela created OAK-1181: --- Summary: Review node type definition for oak:queryIndexDefinition Key: OAK-1181 URL: https://issues.apache.org/jira/browse/OAK-1181 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela things to review: - extending from nt:unstructured - OPV flags (behavior upon versioning of the parent node) - incomplete list of properties compared to those mentioned in query.md - 'async' property is string with a predefined value 'async': why not boolean? - index content stored underneath the definition has not dedicated node type. things to consider: - is it expected that an index definition has custom properties? - is it expected that such custom properties have other property types that STRING/NAME/BOOLEAN? e.g. a binary? - is it expected that an index definition has other child nodes that the index content itself? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1181) Review node type definition for oak:queryIndexDefinition
[ https://issues.apache.org/jira/browse/OAK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1181: Description: things to review: - name not following naming convention - extending from nt:unstructured - OPV flags (behavior upon versioning of the parent node) - incomplete list of properties compared to those mentioned in query.md - 'async' property is string with a predefined value 'async': why not boolean? - index content stored underneath the definition has not dedicated node type. things to consider: - is it expected that an index definition has custom properties? - is it expected that such custom properties have other property types that STRING/NAME/BOOLEAN? e.g. a binary? - is it expected that an index definition has other child nodes that the index content itself? was: things to review: - extending from nt:unstructured - OPV flags (behavior upon versioning of the parent node) - incomplete list of properties compared to those mentioned in query.md - 'async' property is string with a predefined value 'async': why not boolean? - index content stored underneath the definition has not dedicated node type. things to consider: - is it expected that an index definition has custom properties? - is it expected that such custom properties have other property types that STRING/NAME/BOOLEAN? e.g. a binary? - is it expected that an index definition has other child nodes that the index content itself? Review node type definition for oak:queryIndexDefinition Key: OAK-1181 URL: https://issues.apache.org/jira/browse/OAK-1181 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela Fix For: 0.14 things to review: - name not following naming convention - extending from nt:unstructured - OPV flags (behavior upon versioning of the parent node) - incomplete list of properties compared to those mentioned in query.md - 'async' property is string with a predefined value 'async': why not boolean? - index content stored underneath the definition has not dedicated node type. things to consider: - is it expected that an index definition has custom properties? - is it expected that such custom properties have other property types that STRING/NAME/BOOLEAN? e.g. a binary? - is it expected that an index definition has other child nodes that the index content itself? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (OAK-1181) Review node type definition for oak:queryIndexDefinition
[
https://issues.apache.org/jira/browse/OAK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821794#comment-13821794
]
angela edited comment on OAK-1181 at 11/13/13 8:29 PM:
---
in this case i would suggest to define oak:queryIndexDefinition as follows:
{code}
/**
* Index definitions storage
*
* @since oak 0.6
*/
[oak:QueryIndexDefinition]
- * (UNDEFINED) IGNORE
- * (UNDEFINED) multiple IGNORE
+ * (nt:base) IGNORE
{code}
this means:
- having specific OPV flag for all items
- allowing any type of single or multivalued property
- allow any type of child nodes
- not allowing SNS by definition
- mandating node type of child node to be specified (according to the needs of
the custom index definition)
- no orderable children
wdyt?
was (Author: anchela):
in this case i would suggest to define oak:queryIndexDefinition as follows:
/**
* Index definitions storage
*
* @since oak 0.6
*/
[oak:QueryIndexDefinition]
- * (UNDEFINED) IGNORE
- * (UNDEFINED) multiple IGNORE
+ * (nt:base) IGNORE
this means:
- having specific OPV flag for all items
- allowing any type of single or multivalued property
- allow any type of child nodes
- not allowing SNS by definition
- mandating node type of child node to be specified (according to the needs of
the custom index definition)
- no orderable children
wdyt?
Review node type definition for oak:queryIndexDefinition
Key: OAK-1181
URL: https://issues.apache.org/jira/browse/OAK-1181
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core
Reporter: angela
Fix For: 0.14
things to review:
- name not following naming convention
- extending from nt:unstructured
- OPV flags (behavior upon versioning of the parent node)
- incomplete list of properties compared to those mentioned in query.md
- 'async' property is string with a predefined value 'async': why not boolean?
- index content stored underneath the definition has not dedicated node type.
things to consider:
- is it expected that an index definition has custom properties?
- is it expected that such custom properties have other property types that
STRING/NAME/BOOLEAN? e.g. a binary?
- is it expected that an index definition has other child nodes that the
index content itself?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1183) UserQuery: Impersonators Constraint does not work for admin/system user
angela created OAK-1183: --- Summary: UserQuery: Impersonators Constraint does not work for admin/system user Key: OAK-1183 URL: https://issues.apache.org/jira/browse/OAK-1183 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela Assignee: angela Priority: Minor the impersonators constraint does not take the special handling for admin/system users into account and thus returns wrong results. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1176) ObservationTest#observationDispose fails every now and then
[ https://issues.apache.org/jira/browse/OAK-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13822502#comment-13822502 ] angela commented on OAK-1176: - tried patch 3 and didn't experience the failure up to now. ObservationTest#observationDispose fails every now and then --- Key: OAK-1176 URL: https://issues.apache.org/jira/browse/OAK-1176 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela Priority: Minor Attachments: OAK-1176-1.patch, OAK-1176-2.patch, OAK-1176-3.patch, org.apache.jackrabbit.oak.jcr.observation.ObservationTest.txt on my computer ObservationTest#observationDispose failes every now and then but always succeeds when i run the oak-jcr tests again after the failure: observationDispose[0](org.apache.jackrabbit.oak.jcr.observation.ObservationTest) Time elapsed: 0.335 sec FAILURE! java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.jackrabbit.oak.jcr.observation.ObservationTest.observationDispose(ObservationTest.java:352) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:695) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1137) Node.getReferences() is slow due to missing property index
[ https://issues.apache.org/jira/browse/OAK-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13825207#comment-13825207 ] angela commented on OAK-1137: - regarding hidden items being exposed by child node count: you need to add any hidden node names to the list at AbstractTree#INTERNAL_NODE_NAMES! we can't loop over all children just to find out if there is a child with a name starting with ':' instead we should keep track of all known hidden names and explicitly filter them out as needed. Node.getReferences() is slow due to missing property index -- Key: OAK-1137 URL: https://issues.apache.org/jira/browse/OAK-1137 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Affects Versions: 0.10 Reporter: Tobias Bocanegra Assignee: Alex Parvulescu Priority: Critical Fix For: 0.12 Attachments: OAK-1137-v2.patch, OAK-1137.patch Node.getReferences() traverses all items in the repository in order to find the properties that reference the given node. this is super slow and does not scale. the (weak) reference properties should be auto-indexed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1137) Node.getReferences() is slow due to missing property index
[ https://issues.apache.org/jira/browse/OAK-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13825244#comment-13825244 ] angela commented on OAK-1137: - see also OAK-1193 for a discussion on how to improve the handling of the INTERNAL_NODE_NAMES. Node.getReferences() is slow due to missing property index -- Key: OAK-1137 URL: https://issues.apache.org/jira/browse/OAK-1137 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Affects Versions: 0.10 Reporter: Tobias Bocanegra Assignee: Alex Parvulescu Priority: Critical Fix For: 0.12 Attachments: OAK-1137-v2.patch, OAK-1137-v3.patch, OAK-1137.patch Node.getReferences() traverses all items in the repository in order to find the properties that reference the given node. this is super slow and does not scale. the (weak) reference properties should be auto-indexed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1201) Implement jackrabbit api specific descriptors
angela created OAK-1201: --- Summary: Implement jackrabbit api specific descriptors Key: OAK-1201 URL: https://issues.apache.org/jira/browse/OAK-1201 Project: Jackrabbit Oak Issue Type: Improvement Components: core, jcr Reporter: angela Assignee: angela add repository descriptions that have been created while addressing JCR-3697 (revision 1543443): their value should be set to true if the corresponding security related features are enabled on the oak repository. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[
https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13713475#comment-13713475
]
angela edited comment on OAK-791 at 11/20/13 10:16 AM:
---
moved to
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-doc/src/site/markdown/differences_user.md
was (Author: anchela):
h4. 1. Characteristics of the Default Implementation
The default user management implementation present with OAK always stores
user/group information in the workspace associated with the editing Session
(see jr2 UserPerWorkspaceUserManager). The implementation of a user mgt variant
corresponding to Jackrabbit's default
UserManagerImpl is blocked by missing workspace handling (see OAK-118).
The current user manager has the following characteristics that differ from the
corresponding Jackrabbit implementation:
h5. General
- Changes made to the user management API are always transient and require
Session#save() to be persisted.
- In case of a failure Session#refresh is no longer called in order to prevent
reverting other changes unrelated to the user mgt operation. Consequently it's
the responsibility of the API consumer to specifically revert pending or
invalid transient modifications.
- The implementation is no longer built on top of the JCR API but instead
directly acts on Tree and PropertyState defined by the OAK API. This move
allows to make use of the user management API within the OAK layer (aka SPI).
h5. User/Group creation
- The rep:password property is no longer defined to be mandatory. Therefore a
new user might be created without specifying a password. Note however, that
User#changePassword does not allow to remove the password property.
- UserManager#createGroup(Principal) will no longer generate a groupID in case
the principal name collides with an existing user or group ID. This has been
considered redundant as the Jackrabbit API in the mean time added
UserManager#createGroup(String groupID).
- Since OAK is designed to scale with flat hierarchies the former configuration
options 'autoExpandTree' and 'autoExpandSize' are no longer supported.
h5. Handling of the Authorizable ID
- As of OAK the node type definition of rep:Authorizable defines a new property
rep:authorizableId which is intended to store the ID of a user or group.
- The default implementation comes with a dedicated property index for
rep:authorizableId which asserts the uniqueness of that ID.
- Authorizable#getID returns the string value contained in rep:authorizableID
and for backwards compatibility falls back on the node name in case the ID
property is missing.
- The name of the authorizable node is generated based on a configurable
implementation of the 'AuthorizableNodeName' interface (see configuration
section below). By default it uses the ID as name hint and includes a
conversion to a valid JCR node name.
h5. Equals and HashCode for Authorizables
The implementation of Object#equals() and Object#hashCode() for user and groups
slightly differs from Jackrabbit 2.x. It no longer relies on the sameness of
the underlaying JCR node but only compares IDs and the user manager instance.
h5. The 'everyone' Group
As in Jackrabbit 2.x the OAK implementation contains special handling for the
optional group corresponding to the {{EveryonePrincipal}} which always contains
all {{Authorizable}} as member. As of OAK this fact is consistently reflected
in all group membership related methods.
_TODO: OAK-949 (query)_
h5. Autosave behavior
Due to the nature of the UserManager (see above) we decided to drop the
auto-save behavior in the default implementation present with OAK. Consequently,
- UserManager#autoSave(boolean) throws UnsupportedRepositoryOperationException
- UserManager#isAutoSave() always returns false
See also PARAM_SUPPORT_AUTOSAVE below; while this should not be needed if
application code has been written against the Jackrabbit API (and thus testing
if auto-save mode is enabled or not) this configuration option can be used as
last resort.
h5. XML Import
As of OAK 1.0 user and group nodes can be imported both with Session and
Workspace import. The difference compare to Jackrabbit are listed below:
- Importing an authorizable to another tree than the configured user/group node
will only failed upon save (- see UserValidator during the Root#commit). With
Jackrabbit core it used to fail immediately.
- NEW: The BestEffort behavior is now also implemented for the import of
impersonators (was missing in JR).
- NEW: Workspace Import
h5. Group Membership
_TODO_ (see OAK-482)
h4. 2. Builtin Users
The setup of builtin user and group accounts is triggered by the configured
WorkspaceInitializer associated with the user management configuration (see
Configuration section below).
The default user mgt implementation in OAK comes with an initializer that
creates the
[jira] [Updated] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-791: --- Fix Version/s: (was: 0.12) UserManagement: Document changes wrt Jackrabbit 2 - Key: OAK-791 URL: https://issues.apache.org/jira/browse/OAK-791 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: angela -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13827526#comment-13827526 ] angela commented on OAK-482: in the docu section it seems that you wanted to redefined the rep:Members node type definition. i would strongly recommend not to do this but keep the original node type definitions as they are but just deprecate them. btw: i find it a bit inconvenient if the docu section is updated before the code is modified. this is asking for outdated and wrong documentation because once we will produce a final release nobody will have time to carefully verify that the docu is updated. i will remove the corresponding section from the documentation. 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] [Commented] (OAK-1205) Enable/Disable security for ImmutableRoot built from a Root
[
https://issues.apache.org/jira/browse/OAK-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827645#comment-13827645
]
angela commented on OAK-1205:
-
IMO this doesn't make too much sense. the current definition of ImmutableRoot is
{code}
Simple implementation of the Root interface that only supports simple read
operations based on the {@code NodeState} (or {@code ImmutableTree})
passed to the constructor. This root implementation provides a query engine
with index support limited to the {@link PropertyIndexProvider}.
{code}
and the immutabletree is defined to be just a simple wrapper around a NodeState
and the whole thing is intended to be used to get the benefit of the
hierarchical information
present with root/tree that is missing with the NodeState API in cases where
you don't
care about permission because you are executing system internal operations.
can you please provide more information what's the background of this issue?
Enable/Disable security for ImmutableRoot built from a Root
---
Key: OAK-1205
URL: https://issues.apache.org/jira/browse/OAK-1205
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Antonio Sanso
Priority: Minor
Attachments: OAK1205-patch.txt
At the moment when invoking the
{code}
public ImmutableRoot(@Nonnull Root root, @Nonnull TreeTypeProvider
typeProvider) {
{code}
constructor there is no way to specify if to specify if the SecureNodeState
should be use or not.
Indeed with the current implementation this is always disabled. It would be
nice to have the explicit choice to have a SecureNodeState or not, e.g. having
{code}
public ImmutableRoot(@Nonnull Root root, @Nonnull TreeTypeProvider
typeProvider, boolean secured) {
{code}
I have discussed this with [~mduerig] and we came up with the patch I will
provide.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13827791#comment-13827791 ] angela commented on OAK-482: regarding node type definitions: it's a node type definition that has been release and IMO is therefore sort of public API. second we need to be able to migrate jr2 group information into oak and i would definitely love to be able to XML import jr2 group information into oak. if we have collisions in node type definitions i feel that this will cause troubles. third changing node type definitions used to be very troublesome in the past... i'd rather want to avoid any kind of issues that may arise here by just not reusing existing node type names for something else... but maybe i am too cautious :-) 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] [Commented] (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:comment-tabpanelfocusedCommentId=13827840#comment-13827840 ] angela commented on OAK-482: my preference would be rep:MemberReferences. but if you have the feeling that my concerns wrt to changing rep:Member are exaggerate, you can give it a try... as long as we have sufficient test coverage. 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] [Commented] (OAK-1206) Consider renaming internal nodetypes
[ https://issues.apache.org/jira/browse/OAK-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827909#comment-13827909 ] angela commented on OAK-1206: - fine with me. Consider renaming internal nodetypes Key: OAK-1206 URL: https://issues.apache.org/jira/browse/OAK-1206 Project: Jackrabbit Oak Issue Type: Bug Reporter: Tobias Bocanegra some new nodetypes have the oak namespace but are used only internally. in jackrabbit 2.x we used the 'internal' namespace for those. I suggest to use the internal namespace for nodes that are not (or should not) be created via JCR, namely: * rep:NodeType * rep:NamedPropertyDefinitions * rep:PropertyDefinitions * rep:PropertyDefinition * rep:NamedChildNodeDefinitions * rep:ChildNodeDefinitions * rep:ChildNodeDefinition see also OAK-1180 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1205) Enable/Disable security for ImmutableRoot built from a Root
[
https://issues.apache.org/jira/browse/OAK-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827891#comment-13827891
]
angela commented on OAK-1205:
-
see my question above. lets' rephrase it:
i still don't understand what kind of problem you try to address... would you
mind providing some more information what's the intention behind your proposal?
that patch doesn't indicate where this would be used, doesn't make use of it in
other areas of the code base and doesn't add any tests that shed some light on
what you are trying to achieve.
Enable/Disable security for ImmutableRoot built from a Root
---
Key: OAK-1205
URL: https://issues.apache.org/jira/browse/OAK-1205
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Antonio Sanso
Priority: Minor
Attachments: OAK1205-patch.txt
At the moment when invoking the
{code}
public ImmutableRoot(@Nonnull Root root, @Nonnull TreeTypeProvider
typeProvider) {
{code}
constructor there is no way to specify if to specify if the SecureNodeState
should be use or not.
Indeed with the current implementation this is always disabled. It would be
nice to have the explicit choice to have a SecureNodeState or not, e.g. having
{code}
public ImmutableRoot(@Nonnull Root root, @Nonnull TreeTypeProvider
typeProvider, boolean secured) {
{code}
I have discussed this with [~mduerig] and we came up with the patch I will
provide.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1207) Change OakRepositoryStubBase to use NodeStore setup
angela created OAK-1207:
---
Summary: Change OakRepositoryStubBase to use NodeStore setup
Key: OAK-1207
URL: https://issues.apache.org/jira/browse/OAK-1207
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: angela
in order to align the default tck setup with our development i would suggest to
change the following line in OakRepositoryStubBase
{quote}
Jcr jcr = new Jcr(new MicroKernelImpl(dir));
{quote}
to use a NodeStore instead.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1206) Consider renaming internal nodetypes
[ https://issues.apache.org/jira/browse/OAK-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827985#comment-13827985 ] angela commented on OAK-1206: - btw: if we address this we should also address this for internal node/property names that use the oak prefix. such as e.g. oak:namespaces. Consider renaming internal nodetypes Key: OAK-1206 URL: https://issues.apache.org/jira/browse/OAK-1206 Project: Jackrabbit Oak Issue Type: Bug Reporter: Tobias Bocanegra some new nodetypes have the oak namespace but are used only internally. in jackrabbit 2.x we used the 'internal' namespace for those. I suggest to use the internal namespace for nodes that are not (or should not) be created via JCR, namely: * rep:NodeType * rep:NamedPropertyDefinitions * rep:PropertyDefinitions * rep:PropertyDefinition * rep:NamedChildNodeDefinitions * rep:ChildNodeDefinitions * rep:ChildNodeDefinition see also OAK-1180 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-190) Use JCR API defined by JSR-333
[ https://issues.apache.org/jira/browse/OAK-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-190: --- Attachment: OAK-190_2.patch updated patch against the latest trunk with additional implementations of methods interfaces added by JSR 333. no tests yet... Use JCR API defined by JSR-333 -- Key: OAK-190 URL: https://issues.apache.org/jira/browse/OAK-190 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: angela Fix For: 0.13 Attachments: OAK-190.patch, OAK-190_2.patch there are quite some improvements in JSR-333 (both spec and api wise) and i think it would make sense to develop jackrabbit3 on the latest version of the specification. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-190) Use JCR API defined by JSR-333
[ https://issues.apache.org/jira/browse/OAK-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-190: --- Attachment: OAK-190_3.patch ... including implementation of some simple convenience methods on Node. one more thing to note: The different rangeiterator interfaces are now defined to extend from Iterable. this means we also had to fix the RangeIteratorAdaptors in jackrabbit-jcr-commons that we use throughout the oak code. Use JCR API defined by JSR-333 -- Key: OAK-190 URL: https://issues.apache.org/jira/browse/OAK-190 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: angela Fix For: 0.13 Attachments: OAK-190.patch, OAK-190_2.patch, OAK-190_3.patch there are quite some improvements in JSR-333 (both spec and api wise) and i think it would make sense to develop jackrabbit3 on the latest version of the specification. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1213) Namespaces index node oak:namespaces should have a primary type
[
https://issues.apache.org/jira/browse/OAK-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13829082#comment-13829082
]
angela commented on OAK-1213:
-
as suggested earlier in other issues i would suggest to define a specific node
type for such repository internal content that might the also be used for
hidden content and so forth... something like
{code}
rep:Unstructured
- * (UNDEFINED) IGNORE
- * (UNDEFINED) multiple IGNORE
+ * (nt:base) IGNORE (or maybe ABORT would be even better)
{code}
i will create an improvement issue to discuss the creation of that node type.
in the mean time you may fix the issue by using nt:unstructured. hope that
works for you and doesn't block you from fixing this issue.
Namespaces index node oak:namespaces should have a primary type
---
Key: OAK-1213
URL: https://issues.apache.org/jira/browse/OAK-1213
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Alex Parvulescu
It looks like the 'oak:namespaces' node is missing a primary node type.
{noformat}
javax.jcr.RepositoryException: Node at
/jcr:system/rep:namespaces/oak:namespaces has no primary type.
at
org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.getEffectiveNodeType(ReadOnlyNodeTypeManager.java:355)
at
org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.getDefinition(ReadOnlyNodeTypeManager.java:405)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl$9.perform(PropertyImpl.java:394)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl$9.perform(PropertyImpl.java:391)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:128)
at
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:113)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getDefinition(PropertyImpl.java:391)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1214) Create rep:Unstructured node type for repo internal content
angela created OAK-1214:
---
Summary: Create rep:Unstructured node type for repo internal
content
Key: OAK-1214
URL: https://issues.apache.org/jira/browse/OAK-1214
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: angela
as mentioned earlier on i somehow dislike the idea of using nt:unstructured for
repository internal content like the hidden index and the namespace index
optimization.
therefore i would like suggest to create the following node type:
{code}
rep:Unstructured
- * (UNDEFINED) IGNORE
- * (UNDEFINED) multiple IGNORE
+ * (nt:base) IGNORE (or maybe ABORT would be even better)
{code}
that doesn't limit the creation of any kind of property and child nodes (except
SNSs), doesn't have orderable child nodes and in addition prevents the subtree
to be copied over to the version store in case the parent node is being made
versionable.
wdyt?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1193) AbstractTree.getChildNodeCount() should not actively filter out hidden names
[
https://issues.apache.org/jira/browse/OAK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13829088#comment-13829088
]
angela commented on OAK-1193:
-
see OAK-1214 for a proposal for such a internal node type that also prevents
the subtree from being copied over to the version store.
AbstractTree.getChildNodeCount() should not actively filter out hidden names
Key: OAK-1193
URL: https://issues.apache.org/jira/browse/OAK-1193
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Tobias Bocanegra
{code}
long count = nodeBuilder.getChildNodeCount(max);
if (count 0) {
for (String name : INTERNAL_NODE_NAMES) {
if (nodeBuilder.hasChildNode(name)) {
count--;
}
}
}
{code}
Checks {{INTERNAL_NODE_NAMES}} which is slow and not extensible. it should
propagate the hidden-filtering down to node builder.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1219) VersionEditor must ignore hidden items
angela created OAK-1219: --- Summary: VersionEditor must ignore hidden items Key: OAK-1219 URL: https://issues.apache.org/jira/browse/OAK-1219 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Assignee: Marcel Reutegger as discussed before the version editor must ignore hidden items (probably except for the child order property) when creating versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1222) Migration of Group Members stored in tree structure
angela created OAK-1222: --- Summary: Migration of Group Members stored in tree structure Key: OAK-1222 URL: https://issues.apache.org/jira/browse/OAK-1222 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela Assignee: Tobias Bocanegra as discussed in OAK-482 we will change the way how 'many' group members are stored in the content and discontinue the former node structure which used to have residual weak reference properties. consequently we have to adjust the group member structure upon migrating from jackrabbit 2.x to oak. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1222) Migration of Group Members stored in tree structure
[ https://issues.apache.org/jira/browse/OAK-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831462#comment-13831462 ] angela commented on OAK-1222: - [~tripod], i assign this to you. please provide instructions regarding migration path in case you want this to be completed by jukka along with the other content migration issues. Migration of Group Members stored in tree structure --- Key: OAK-1222 URL: https://issues.apache.org/jira/browse/OAK-1222 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela Assignee: Tobias Bocanegra Fix For: 0.13 as discussed in OAK-482 we will change the way how 'many' group members are stored in the content and discontinue the former node structure which used to have residual weak reference properties. consequently we have to adjust the group member structure upon migrating from jackrabbit 2.x to oak. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1223) Inconsistent entry filtering for ADD_NODE permission
angela created OAK-1223: --- Summary: Inconsistent entry filtering for ADD_NODE permission Key: OAK-1223 URL: https://issues.apache.org/jira/browse/OAK-1223 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela in order to be able to add a new now jcr:addChildNodes privilege must be granted on the parent node. while this properly handled upon permission evaluation the filtering of the entries prior to the evaluation does not handle this properly. consequently entries that apply to the parent are filtered out preemptively. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-1220) SessionMoveTest.testMoveAndRemoveSubTree3 fails with SegmentMK+FileStore
[ https://issues.apache.org/jira/browse/OAK-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned OAK-1220: --- Assignee: angela SessionMoveTest.testMoveAndRemoveSubTree3 fails with SegmentMK+FileStore Key: OAK-1220 URL: https://issues.apache.org/jira/browse/OAK-1220 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Affects Versions: 0.11 Reporter: Marcel Reutegger Assignee: angela Priority: Minor Attachments: org.apache.jackrabbit.oak.jcr.security.authorization.SessionMoveTest.txt Changing the OakRepositoryStubBase to use SegmentMK+FileStore results in a test failure in SessionMoveTest#testMoveAndRemoveSubTree3 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OAK-1220) SessionMoveTest.testMoveAndRemoveSubTree3 fails with SegmentMK+FileStore
[ https://issues.apache.org/jira/browse/OAK-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831555#comment-13831555 ] angela commented on OAK-1220: - i will take a look... the whole move handling in the permission evaluation is work in progress. SessionMoveTest.testMoveAndRemoveSubTree3 fails with SegmentMK+FileStore Key: OAK-1220 URL: https://issues.apache.org/jira/browse/OAK-1220 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Affects Versions: 0.11 Reporter: Marcel Reutegger Assignee: angela Priority: Minor Attachments: org.apache.jackrabbit.oak.jcr.security.authorization.SessionMoveTest.txt Changing the OakRepositoryStubBase to use SegmentMK+FileStore results in a test failure in SessionMoveTest#testMoveAndRemoveSubTree3 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1220) SessionMoveTest.testMoveAndRemoveSubTree3 fails with SegmentMK+FileStore
[ https://issues.apache.org/jira/browse/OAK-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1220. - Resolution: Fixed with the latest changes made the test passed on my checkout even if patch from OAK-1207 is applied. if the problem persists, feel free to add the test to the exclusion list in order not to block OAK-1207. SessionMoveTest.testMoveAndRemoveSubTree3 fails with SegmentMK+FileStore Key: OAK-1220 URL: https://issues.apache.org/jira/browse/OAK-1220 Project: Jackrabbit Oak Issue Type: Bug Components: core, jcr Affects Versions: 0.11 Reporter: Marcel Reutegger Assignee: angela Priority: Minor Attachments: org.apache.jackrabbit.oak.jcr.security.authorization.SessionMoveTest.txt Changing the OakRepositoryStubBase to use SegmentMK+FileStore results in a test failure in SessionMoveTest#testMoveAndRemoveSubTree3 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1201) Implement jackrabbit api specific descriptors
[ https://issues.apache.org/jira/browse/OAK-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1201: Fix Version/s: 0.13 Implement jackrabbit api specific descriptors - Key: OAK-1201 URL: https://issues.apache.org/jira/browse/OAK-1201 Project: Jackrabbit Oak Issue Type: Improvement Components: core, jcr Reporter: angela Assignee: angela Fix For: 0.13 Attachments: OAK-1201.patch add repository descriptions that have been created while addressing JCR-3697 (revision 1543443): their value should be set to true if the corresponding security related features are enabled on the oak repository. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1201) Implement jackrabbit api specific descriptors
[ https://issues.apache.org/jira/browse/OAK-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1201: Attachment: OAK-1201.patch Implement jackrabbit api specific descriptors - Key: OAK-1201 URL: https://issues.apache.org/jira/browse/OAK-1201 Project: Jackrabbit Oak Issue Type: Improvement Components: core, jcr Reporter: angela Assignee: angela Fix For: 0.13 Attachments: OAK-1201.patch add repository descriptions that have been created while addressing JCR-3697 (revision 1543443): their value should be set to true if the corresponding security related features are enabled on the oak repository. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1228) Update jackrabbit dependency to 2.7.3
angela created OAK-1228: --- Summary: Update jackrabbit dependency to 2.7.3 Key: OAK-1228 URL: https://issues.apache.org/jira/browse/OAK-1228 Project: Jackrabbit Oak Issue Type: Wish Components: parent Reporter: angela Assignee: Alex Parvulescu Priority: Minor Fix For: 0.13 in order to be able to resolve OAK-1201 the most recent changes made to JackrabbitRepository (constants for api specific descriptors) should be available in oak. as discussed with [~alex.parvulescu] i will commit the fix for OAK-1201 after the 0.12 release including a snapshot dependency. this issue acts as marker in order to revert back to a regular jr dependency before releasing 0.13. -- This message was sent by Atlassian JIRA (v6.1#6144)
[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=13832792#comment-13832792 ] angela commented on OAK-884: [~asanso] why does the patch introduce a dependency to jackrabbit-core and jackrabbit-jcr-server? please clarify, thanks. 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, 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] [Comment Edited] (OAK-1230) Write access control of touched content
[
https://issues.apache.org/jira/browse/OAK-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833583#comment-13833583
]
angela edited comment on OAK-1230 at 11/27/13 8:58 AM:
---
and the same arises with the move-permission story:
if a tree structure is moved away and the identical structure is re-created at
the original source (not even modifying the child-order), the current setup
will detect that there was a move but the permission validator will not detect
that the replacement tree has been created. currently i am inclined to ignore
this in order to keep it consistent with any other kind of validation. *if* we
wanted to address this we have to re-evaluate the option of using a changelog
as michael suggested at the very early days of the oak project.
we can discuss this again at the next oakathon but if we decided to resolve
this kind of issues as wontfix we should update the diff-documentation such
that it's really clear for everyone what the implications are.
was (Author: anchela):
and the same arises with the move-permission story:
if a tree structure is moved away and the identical structure is re-created at
the original source (not even modifying the child-order), the is now a way to
detect that there was a move but the permission validator will not detect that
the replacement tree has been created. currently i am inclined to ignore this
in order to keep it consistent with any other kind of validation. *if* we
wanted to address this we have to re-evaluate the option of using a changelog
as michael suggested at the very early days of the oak project.
we can discuss this again at the next oakathon but if we decided to resolve
this kind of issues as wontfix we should update the diff-documentation such
that it's really clear for everyone what the implications are.
Write access control of touched content
-
Key: OAK-1230
URL: https://issues.apache.org/jira/browse/OAK-1230
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Jukka Zitting
Labels: security
Following up from OAK-928 and OAK-948 to clarify the interesting case of
updates that set a property (or a broader subtree of content) to the exact
same value that it used to have.
Since such touching of content results in an empty content diff, the
{{PermissionValidator}} doesn't get invoked and thus write access controls
are not checked. Additionally (as reported in OAK-948) no observation events
get sent for such updates. This seems like a reasonable thing to do, as if
nothing changes there should be no need to check for write access or to
inform observation listeners.
However, OAK-928 makes this case trickier, as it opens a possibility to use
brute force to circumvent read access controls for certain kinds of content.
For example, if an attacker knows (or can guess) the existence of a certain
read/write-protected property (e.g. some sensitive configuration setting),
it's possible to repeatedly try to update that property with different likely
values. Normally the update would fail with an exception because of the write
protection, but when the attempted update matches the stored value there
would be no exception because no change gets detected. At that point the
attacker would know what the stored value is!
The above scenario is somewhat artificial as it only works for highly
specific cases, so I'm not sure how important it is for us to address this
case at the repository level.
If we don't address this then a simple workaround for security-sensitive
content would be to deny read access to the whole containing node and add a
property containing a random value along the sensitive information. That
would make it impossible for the attacker to use this mechanism to guess the
sensitive bits, as they'd also need to guess what the random value is.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1232) Improve implementation of Tree.get(Property)Status
[
https://issues.apache.org/jira/browse/OAK-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833605#comment-13833605
]
angela commented on OAK-1232:
-
afaik there exists another issue stating that Property#getStatus requires read
access to the parent node:
OAK-212 and OAK-220
IMHO the status of an accessible property should be obtained without taking the
accessibility of the parent node into account. am i missing something that
would prevent us from doing this?
Improve implementation of Tree.get(Property)Status
---
Key: OAK-1232
URL: https://issues.apache.org/jira/browse/OAK-1232
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Priority: Minor
OAK-928 introduced methods for determining the status of a property from a
{{NodeBuilder}}. The implementations of {{Tree.getPropertyStatus}} should
change using these new methods instead of duplicating the logic.
Furthermore the since the {{get(Propert)Status}} methods pre-dates the
introduction of the {{exists}} method, we should also clarify the effect of
calling such methods on a non existing tree.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (OAK-1232) Improve implementation of Tree.get(Property)Status
[
https://issues.apache.org/jira/browse/OAK-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833605#comment-13833605
]
angela edited comment on OAK-1232 at 11/27/13 9:27 AM:
---
+1 for the clean up.
regarding interaction with Tree#exists:
afaik there exists another issue stating that Property#getStatus requires read
access to the parent node:
OAK-212 and OAK-220
IMHO the status of an accessible property should be obtained without taking the
accessibility of the parent node into account. am i missing something that
would prevent us from doing this?
was (Author: anchela):
afaik there exists another issue stating that Property#getStatus requires read
access to the parent node:
OAK-212 and OAK-220
IMHO the status of an accessible property should be obtained without taking the
accessibility of the parent node into account. am i missing something that
would prevent us from doing this?
Improve implementation of Tree.get(Property)Status
---
Key: OAK-1232
URL: https://issues.apache.org/jira/browse/OAK-1232
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Priority: Minor
OAK-928 introduced methods for determining the status of a property from a
{{NodeBuilder}}. The implementations of {{Tree.getPropertyStatus}} should
change using these new methods instead of duplicating the logic.
Furthermore the since the {{get(Propert)Status}} methods pre-dates the
introduction of the {{exists}} method, we should also clarify the effect of
calling such methods on a non existing tree.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[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=13833813#comment-13833813 ] angela commented on OAK-884: ok... i applied it again, moved it to a separate package 'random' and wanted to extract the setup into an abstract base test such that we can use this as a starting point of a more comprehensive test library of that kind of randomized tests. while doing so i found that the complete setup is done in the static beforeClass method: i don't think this is a good idea. all sessions should be logged in in the non-static before test-setup and should be released in the after teardown call. similarly all modifications made by the test including creating nodes, users and so forth should be done for every single test. [~asanso], may i ask you to refactor the test accordingly. thanks. 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, 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] [Commented] (OAK-372) Integrate PropertyBuilder with NodeBuilder
[
https://issues.apache.org/jira/browse/OAK-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836563#comment-13836563
]
angela commented on OAK-372:
Committed revision 1547041: moved and renamed the test cases
Integrate PropertyBuilder with NodeBuilder
--
Key: OAK-372
URL: https://issues.apache.org/jira/browse/OAK-372
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Priority: Minor
In revision 1396640 I introduced the {{PropertyBuilder}} class for building
{{PropertyState}} instances. It would be useful if property builders could
directly be acquired from a {{NodeBuilder}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-372) Integrate PropertyBuilder with NodeBuilder
[
https://issues.apache.org/jira/browse/OAK-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836559#comment-13836559
]
angela commented on OAK-372:
Committed revision 1547034: as discussed during the oakathon i removed the
PropertyUtil and the PropertyBuilder interface and moved the
MemoryPropertyBuilder as PropertyBuilder to the util package.
In a second step we may want to improve the PropertyBuilder util as it
currently only allows to pass the single-valued types. this leads to the
strange situation that PropertyBuilder#create takes a type *and* an isArray
flag.
Integrate PropertyBuilder with NodeBuilder
--
Key: OAK-372
URL: https://issues.apache.org/jira/browse/OAK-372
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Priority: Minor
In revision 1396640 I introduced the {{PropertyBuilder}} class for building
{{PropertyState}} instances. It would be useful if property builders could
directly be acquired from a {{NodeBuilder}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-372) Integrate PropertyBuilder with NodeBuilder
[
https://issues.apache.org/jira/browse/OAK-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836627#comment-13836627
]
angela commented on OAK-372:
simplified the propertybuilder in Revision: 1547060
michael tried to address the oddity with the array flag but i doesn't seem
feasible. let's resolve this fixed for now.
Integrate PropertyBuilder with NodeBuilder
--
Key: OAK-372
URL: https://issues.apache.org/jira/browse/OAK-372
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Michael Dürig
Priority: Minor
Fix For: 0.13
In revision 1396640 I introduced the {{PropertyBuilder}} class for building
{{PropertyState}} instances. It would be useful if property builders could
directly be acquired from a {{NodeBuilder}}.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-1201) Implement jackrabbit api specific descriptors
[ https://issues.apache.org/jira/browse/OAK-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1201. - Resolution: Fixed Implement jackrabbit api specific descriptors - Key: OAK-1201 URL: https://issues.apache.org/jira/browse/OAK-1201 Project: Jackrabbit Oak Issue Type: Improvement Components: core, jcr Reporter: angela Assignee: angela Fix For: 0.13 Attachments: OAK-1201.patch add repository descriptions that have been created while addressing JCR-3697 (revision 1543443): their value should be set to true if the corresponding security related features are enabled on the oak repository. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (OAK-1256) Dead code in PrivilegeBitsProvider#getPrivilegeNames
[
https://issues.apache.org/jira/browse/OAK-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-1256:
---
Assignee: angela
Dead code in PrivilegeBitsProvider#getPrivilegeNames
Key: OAK-1256
URL: https://issues.apache.org/jira/browse/OAK-1256
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Antonio Sanso
Assignee: angela
Attachments: OAK-1256-patch.txt
There is some dead code in PrivilegeBitsProvider#getPrivilegeNames due the
lack of hashCode/equals in PrivileveBits$ModifiableData
More specifically
{code}
SetString privilegeNames;
if (bitsToNames.containsKey(privilegeBits)) {
privilegeNames = bitsToNames.get(privilegeBits);
} else {
{code}
will always be false. Patch to follow
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (OAK-1256) Dead code in PrivilegeBitsProvider#getPrivilegeNames
[
https://issues.apache.org/jira/browse/OAK-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837783#comment-13837783
]
angela commented on OAK-1256:
-
hm... i'd rather not add hashcode/equals to the modifiable data but rather use
the unmodifiable presentation for the lookup.
Dead code in PrivilegeBitsProvider#getPrivilegeNames
Key: OAK-1256
URL: https://issues.apache.org/jira/browse/OAK-1256
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Antonio Sanso
Attachments: OAK-1256-patch.txt
There is some dead code in PrivilegeBitsProvider#getPrivilegeNames due the
lack of hashCode/equals in PrivileveBits$ModifiableData
More specifically
{code}
SetString privilegeNames;
if (bitsToNames.containsKey(privilegeBits)) {
privilegeNames = bitsToNames.get(privilegeBits);
} else {
{code}
will always be false. Patch to follow
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (OAK-1256) Dead code in PrivilegeBitsProvider#getPrivilegeNames
[
https://issues.apache.org/jira/browse/OAK-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-1256.
-
Resolution: Fixed
Fix Version/s: 0.13
fixed by using the unmodifiable representation in the provider (instead of just
using them at the end for adding the result to the map).
thanks for spotting though.
Dead code in PrivilegeBitsProvider#getPrivilegeNames
Key: OAK-1256
URL: https://issues.apache.org/jira/browse/OAK-1256
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Antonio Sanso
Assignee: angela
Fix For: 0.13
Attachments: OAK-1256-patch.txt
There is some dead code in PrivilegeBitsProvider#getPrivilegeNames due the
lack of hashCode/equals in PrivileveBits$ModifiableData
More specifically
{code}
SetString privilegeNames;
if (bitsToNames.containsKey(privilegeBits)) {
privilegeNames = bitsToNames.get(privilegeBits);
} else {
{code}
will always be false. Patch to follow
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (OAK-1261) Enable LDAP related tests
angela created OAK-1261: --- Summary: Enable LDAP related tests Key: OAK-1261 URL: https://issues.apache.org/jira/browse/OAK-1261 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela currently all LDAP related tests are ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (OAK-1183) UserQuery: Impersonators Constraint does not work for admin user
[ https://issues.apache.org/jira/browse/OAK-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1183: Summary: UserQuery: Impersonators Constraint does not work for admin user (was: UserQuery: Impersonators Constraint does not work for admin/system user) UserQuery: Impersonators Constraint does not work for admin user Key: OAK-1183 URL: https://issues.apache.org/jira/browse/OAK-1183 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela Assignee: angela Priority: Minor Fix For: 0.15 the impersonators constraint does not take the special handling for admin/system users into account and thus returns wrong results. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-1183) UserQuery: Impersonators Constraint does not work for admin user
[ https://issues.apache.org/jira/browse/OAK-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1183. - Resolution: Fixed Fix Version/s: (was: 0.15) 0.13 UserQuery: Impersonators Constraint does not work for admin user Key: OAK-1183 URL: https://issues.apache.org/jira/browse/OAK-1183 Project: Jackrabbit Oak Issue Type: Sub-task Components: core, jcr Reporter: angela Assignee: angela Priority: Minor Fix For: 0.13 the impersonators constraint does not take the special handling for admin/system users into account and thus returns wrong results. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (OAK-1267) Failure in ObservationRefreshTest
angela created OAK-1267: --- Summary: Failure in ObservationRefreshTest Key: OAK-1267 URL: https://issues.apache.org/jira/browse/OAK-1267 Project: Jackrabbit Oak Issue Type: Bug Reporter: angela Failed tests: observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest): added nodes expected:1000 but was:442 Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 106.957 sec FAILURE! observation[3](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest) Time elapsed: 53.047 sec FAILURE! java.lang.AssertionError: added nodes expected:1000 but was:906 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:695) observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest) Time elapsed: 58.379 sec FAILURE! java.lang.AssertionError: added nodes expected:1000 but was:396 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at
[jira] [Commented] (OAK-1267) Failure in ObservationRefreshTest
[ https://issues.apache.org/jira/browse/OAK-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840311#comment-13840311 ] angela commented on OAK-1267: - i marked the test with @Ignore... according to tobi it doesn't necessarily fail but might just be too slow. after all, a similar test consistently failed on my machine at revision r1547468 but succeeded with the latest trunk. Failure in ObservationRefreshTest -- Key: OAK-1267 URL: https://issues.apache.org/jira/browse/OAK-1267 Project: Jackrabbit Oak Issue Type: Bug Reporter: angela Failed tests: observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest): added nodes expected:1000 but was:442 Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 106.957 sec FAILURE! observation[3](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest) Time elapsed: 53.047 sec FAILURE! java.lang.AssertionError: added nodes expected:1000 but was:906 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:695) observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest) Time elapsed: 58.379 sec FAILURE! java.lang.AssertionError: added nodes expected:1000 but was:396 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at
[jira] [Created] (OAK-1268) Add support for composite authorization setup
angela created OAK-1268: --- Summary: Add support for composite authorization setup Key: OAK-1268 URL: https://issues.apache.org/jira/browse/OAK-1268 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: angela Assignee: angela it would be desirable if was not only be able to replace the default authorization setup but instead being able to plug custom implementations such that they can be combined with existing implementation(s). while this is more or less straight forward for the access control management part, we need some further refinement that allows to define how different permission providers will interact. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (OAK-884) Add simple acl randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-884. Resolution: Fixed i moved the tests to o.a.j.oak.jcr.random as IMO these test are not specific for the security area and applied the patch with minor modifications (formatting) but without taking a closer look. 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.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Updated] (OAK-710) PermissionValidator: Proper permission evaluation for moving/renaming nodes
[ https://issues.apache.org/jira/browse/OAK-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-710: --- Fix Version/s: 0.15 PermissionValidator: Proper permission evaluation for moving/renaming nodes --- Key: OAK-710 URL: https://issues.apache.org/jira/browse/OAK-710 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela Assignee: angela Fix For: 0.15 In jr-core renaming/moving nodes just this just requires MODIFY_CHILD_NODE_COLLECTION permission instead of remove + add node. However, the Validator interface currently doesn't allow for easy detection of move/rename operations. For backwards compatibility it was desirable to find a solution for this open issue. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (OAK-710) PermissionValidator: Proper permission evaluation for moving/renaming nodes
[ https://issues.apache.org/jira/browse/OAK-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-710: --- Fix Version/s: (was: 0.14) PermissionValidator: Proper permission evaluation for moving/renaming nodes --- Key: OAK-710 URL: https://issues.apache.org/jira/browse/OAK-710 Project: Jackrabbit Oak Issue Type: Sub-task Components: core Reporter: angela Assignee: angela Fix For: 0.15 In jr-core renaming/moving nodes just this just requires MODIFY_CHILD_NODE_COLLECTION permission instead of remove + add node. However, the Validator interface currently doesn't allow for easy detection of move/rename operations. For backwards compatibility it was desirable to find a solution for this open issue. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Reopened] (OAK-884) Add simple acl randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reopened OAK-884: the tests fail. i will exclude them. @asanso, any idea why the tests fail? here the output: Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.107 sec FAILURE! testReadAcl(org.apache.jackrabbit.oak.jcr.random.SimpleAclRandomizedTest) Time elapsed: 0.104 sec ERROR! javax.jcr.RepositoryException: Unable to access a repository with the default settings. The following RepositoryFactory classes were consulted: org.apache.jackrabbit.oak.jcr.OakRepositoryFactory: declined org.apache.jackrabbit.commons.JndiRepositoryFactory: declined Perhaps the repository you are trying to access is not available at the moment. at org.apache.jackrabbit.commons.JcrUtils.getRepository(JcrUtils.java:223) at org.apache.jackrabbit.commons.JcrUtils.getRepository(JcrUtils.java:109) at org.apache.jackrabbit.oak.jcr.random.AbstractRandomizedTest.setUp(AbstractRandomizedTest.java:64) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) 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:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) testReadAcl(org.apache.jackrabbit.oak.jcr.random.SimpleAclRandomizedTest) Time elapsed: 0.105 sec ERROR! java.lang.NullPointerException at org.apache.jackrabbit.oak.jcr.random.SimpleAclRandomizedTest.clearTree(SimpleAclRandomizedTest.java:63) at org.apache.jackrabbit.oak.jcr.random.AbstractRandomizedTest.tearDown(AbstractRandomizedTest.java:97) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at
[jira] [Updated] (OAK-884) Add simple acl randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-884: --- Assignee: (was: angela) 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 Fix For: 0.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[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=13844498#comment-13844498 ] angela commented on OAK-884: unassigning from angela 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 Fix For: 0.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Updated] (OAK-884) Add simple randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-884: --- Summary: Add simple randomized test (was: Add simple acl randomized test) Add simple 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 Fix For: 0.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Commented] (OAK-884) Add simple randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845240#comment-13845240 ] angela commented on OAK-884: oh. thanks... but it still fails on my machine. while trying to find the source of the problem i had another look at the code and to be honest i am a bit disappointed about the overall quality of the patch: - the tear down will throw NPE if something went wrong during the setup - the code is over complicated and could be heavily simplified if you would keep just the list read and write sessions irrespective of their origin. - the test modifies the root node without reverting the changes, which may later on cause troubles with other test cases. - typos in method names - ... Add simple 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 Fix For: 0.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Comment Edited] (OAK-884) Add simple randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845240#comment-13845240 ] angela edited comment on OAK-884 at 12/11/13 10:09 AM: --- oh. thanks... but it still fails on my machine. while trying to find the source of the problem i had another look at the code and to be honest i am a bit disappointed about the overall quality of the patch: - the tear down will throw NPE if something went wrong during the setup - the code is over complicated and could be heavily simplified if you would keep just the list read and write sessions irrespective of their origin. - the test modifies the root node without reverting the changes, which may later on cause troubles with other test cases. - typos in method names - setting up the user/groups looks quite odd and instead of just doing it in one step you create the user first and the retrieve it by principal (which might be expensive) and add it to the group... you already had the user at hand, why retrieving it again? - ... was (Author: anchela): oh. thanks... but it still fails on my machine. while trying to find the source of the problem i had another look at the code and to be honest i am a bit disappointed about the overall quality of the patch: - the tear down will throw NPE if something went wrong during the setup - the code is over complicated and could be heavily simplified if you would keep just the list read and write sessions irrespective of their origin. - the test modifies the root node without reverting the changes, which may later on cause troubles with other test cases. - typos in method names - ... Add simple 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 Fix For: 0.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Comment Edited] (OAK-884) Add simple randomized test
[
https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845240#comment-13845240
]
angela edited comment on OAK-884 at 12/11/13 10:20 AM:
---
oh. thanks... but it still fails on my machine.
while trying to find the source of the problem i had another look at the code
and to be honest i am a bit disappointed about the overall quality of the patch:
- the tear down will throw NPE if something went wrong during the setup
- the code is over complicated and could be heavily simplified if you would
keep just the list read and write sessions irrespective of their origin.
- the test modifies the root node without reverting the changes, which may
later on cause
troubles with other test cases.
- typos in method names
- setting up the user/groups looks quite odd and instead of just doing it in
one step you create the user first and the retrieve it by principal (which
might be expensive) and add it to the group... you already had the user at
hand, why retrieving it again?
- probable the following check should be for the authorizable not for the id:
{code}
Authorizable authorizable = userManager.getAuthorizable(id);
if (id != null) {
authorizable.remove();
}
{code}
- ...
was (Author: anchela):
oh. thanks... but it still fails on my machine.
while trying to find the source of the problem i had another look at the code
and to be honest i am a bit disappointed about the overall quality of the patch:
- the tear down will throw NPE if something went wrong during the setup
- the code is over complicated and could be heavily simplified if you would
keep just the list read and write sessions irrespective of their origin.
- the test modifies the root node without reverting the changes, which may
later on cause
troubles with other test cases.
- typos in method names
- setting up the user/groups looks quite odd and instead of just doing it in
one step you create the user first and the retrieve it by principal (which
might be expensive) and add it to the group... you already had the user at
hand, why retrieving it again?
- ...
Add simple 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
Fix For: 0.14
Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Resolved] (OAK-884) Add simple randomized test
[ https://issues.apache.org/jira/browse/OAK-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-884. Resolution: Fixed added the dependency (jackrabbit-core is listed twice now) and added major simplification to the tests. Add simple 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 Fix For: 0.14 Attachments: OAK-884-patch.txt, OAK-884-patch.txt, 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.4#6159)
[jira] [Resolved] (OAK-783) Reflect Move and Rename upon Root#commit
[ https://issues.apache.org/jira/browse/OAK-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-783. Resolution: Fixed Reflect Move and Rename upon Root#commit Key: OAK-783 URL: https://issues.apache.org/jira/browse/OAK-783 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Fix For: 0.14 right now rename and move operations cannot be identified during commit processing in validators or commit hooks. for proper (and backwards compatible) permission evaluation however we need the ability to distinguish between moving a node around or having nodes + properties being removed and added. during the last oakathon michael and myself had a discussion regarding that issue and michael convinced me that this can't be achieved by simply passing the move information contained in RootImpl to the commit hook. therefore creating this issue to track progress and discussions regarding move and renaming. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (OAK-652) ItemImpl.checkProtected() is too slow
[
https://issues.apache.org/jira/browse/OAK-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-652.
Resolution: Fixed
ItemImpl.checkProtected() is too slow
-
Key: OAK-652
URL: https://issues.apache.org/jira/browse/OAK-652
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Jukka Zitting
Labels: performance
Fix For: 0.14
As mentioned in http://markmail.org/message/6jktvy53wqyhxlht, with the
current node type code the {{ItemImpl.checkProtected()}} call is pretty
expensive. I profiled simple {{addNode}} and {{setProperty}} calls and got
the following results (showing relative time spent in each method):
{code}
org.apache.jackrabbit.oak.jcr.NodeImpl.addNode
61% org.apache.jackrabbit.oak.jcr.SessionDelegate.perform
39% org.apache.jackrabbit.oak.jcr.ItemImpl.checkProtected
org.apache.jackrabbit.oak.jcr.NodeImpl.setProperty
100% org.apache.jackrabbit.oak.jcr.NodeImpl.internalSetProperty
55% org.apache.jackrabbit.oak.jcr.ItemImpl.checkProtected
45% org.apache.jackrabbit.oak.jcr.SessionDelegate.perform
{code}
By keeping explicit track of effective node types and item definitions we
could probably drive down the cost at least one order of magnitude, but as
mentioned on oak-dev@ I'd rather avoid the call entirely since the relevant
constraints are in any case checked during save().
This issue exists to track either the removal or optimization of the
checkProtected(), depending on what consensus we reach.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (OAK-1163) Observation events should respect permissions
[
https://issues.apache.org/jira/browse/OAK-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-1163.
-
Resolution: Fixed
Assignee: (was: Michael Dürig)
Observation events should respect permissions
-
Key: OAK-1163
URL: https://issues.apache.org/jira/browse/OAK-1163
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core, jcr, security
Reporter: Alexander Klimetschek
Labels: observation
Fix For: 0.14
The JCR observation implementation in Oak does not evaluate ACLs yet, so any
session currently sees all events. {{SecureValidator}} is the intended place
to do the checks.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (OAK-41) Initial repository setup
[ https://issues.apache.org/jira/browse/OAK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-41. --- Resolution: Fixed Initial repository setup Key: OAK-41 URL: https://issues.apache.org/jira/browse/OAK-41 Project: Jackrabbit Oak Issue Type: Task Components: core Reporter: angela Fix For: 0.14 Attachments: OAK-41-initial-proposal.patch, OAK-41-register-namespaces.patch upon the initial creation of a JCR repository the associated SPI layer (oak-core) should take care of setting up the corresponding MK-instance. this includes (incomplete list): - create the jcr repo (not sure what that means in terms of mk-implementation) - create the jcr:system node (unique for the repository, across workspaces) - create the default workspace (- name from config) - create the root node of the default workspace in addition the repository would need to have access to the following information (maybe also mk-nodes underneath jcr:system ??) - built-in node types - built-in namespace - built-in privileges - built-in permissions - repository configuration (can that be stored in the mk?) as far as the workspace is concerned a functional repository would in addition need to have: - build-in users (based on some sort of configuration) - workspace configuration -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (OAK-1237) RTC: Move org.apache.jackrabbit.oak.api.AbstractPropertyState out of api package
[
https://issues.apache.org/jira/browse/OAK-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-1237.
-
Resolution: Fixed
move to plugins.memory
RTC: Move org.apache.jackrabbit.oak.api.AbstractPropertyState out of api
package
Key: OAK-1237
URL: https://issues.apache.org/jira/browse/OAK-1237
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
Fix For: 0.14
{{org.apache.jackrabbit.oak.api.AbstractPropertyState}} is merely a helper
and should not be part of the API package.
suggest to move it to: {{org.apache.jackrabbit.oak.util}}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (OAK-1284) Root.commit(String, CommitHook) : CommitHook is not part of oak-api
[ https://issues.apache.org/jira/browse/OAK-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1284: Fix Version/s: 0.15 Root.commit(String, CommitHook) : CommitHook is not part of oak-api --- Key: OAK-1284 URL: https://issues.apache.org/jira/browse/OAK-1284 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Fix For: 0.15 [~fmeschbe] had a look at the oak api and spotted the following problem: Root#commit(String, CommitHook) But the CommitHook interface is not part of the OAK API. we quickly searched for usages and found that this is only used for the Item#save case in oak-jcr to assert that the set of modifications is contained with the subtree defined by the specified target item. IMO we should get rid of the flavour of Root#commit again and solve the Item-save issue differently. For example we could change it to Root#commit(String, String absPath) where the absPath would be the path of the target item... -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (OAK-1284) Root.commit(String, CommitHook) : CommitHook is not part of oak-api
[ https://issues.apache.org/jira/browse/OAK-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1284: Component/s: core Root.commit(String, CommitHook) : CommitHook is not part of oak-api --- Key: OAK-1284 URL: https://issues.apache.org/jira/browse/OAK-1284 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Fix For: 0.15 [~fmeschbe] had a look at the oak api and spotted the following problem: Root#commit(String, CommitHook) But the CommitHook interface is not part of the OAK API. we quickly searched for usages and found that this is only used for the Item#save case in oak-jcr to assert that the set of modifications is contained with the subtree defined by the specified target item. IMO we should get rid of the flavour of Root#commit again and solve the Item-save issue differently. For example we could change it to Root#commit(String, String absPath) where the absPath would be the path of the target item... -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (OAK-1285) QueryEngine#executeQuery takes NamePathMapper which is not part of oak-api
angela created OAK-1285: --- Summary: QueryEngine#executeQuery takes NamePathMapper which is not part of oak-api Key: OAK-1285 URL: https://issues.apache.org/jira/browse/OAK-1285 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela [~fmeschbe] spotted the following inconsistency in the oak api: o.a.j.o.api.QueryEngine#executeQuery(String statement, String language, long limit, long offset, MapString, ? extends PropertyValue bindings, NamePathMapper namePathMapper) throws ParseException; takes a NamePathMapper which is not part of the oak api but only defined in the plugins. to resolve that inconsistency we may consider moving the NamePathMapper to a new o.a.j.oak.api.namepath package and keep the implementations in the plugins. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (OAK-1285) QueryEngine#executeQuery takes NamePathMapper which is not part of oak-api
[ https://issues.apache.org/jira/browse/OAK-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1285: Fix Version/s: 0.15 QueryEngine#executeQuery takes NamePathMapper which is not part of oak-api -- Key: OAK-1285 URL: https://issues.apache.org/jira/browse/OAK-1285 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Fix For: 0.15 [~fmeschbe] spotted the following inconsistency in the oak api: o.a.j.o.api.QueryEngine#executeQuery(String statement, String language, long limit, long offset, MapString, ? extends PropertyValue bindings, NamePathMapper namePathMapper) throws ParseException; takes a NamePathMapper which is not part of the oak api but only defined in the plugins. to resolve that inconsistency we may consider moving the NamePathMapper to a new o.a.j.oak.api.namepath package and keep the implementations in the plugins. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (OAK-1124) OAK-938 incomplete: session refresh must also be reflected on derived interfaces
[ https://issues.apache.org/jira/browse/OAK-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1124. - Resolution: Fixed OAK-938 incomplete: session refresh must also be reflected on derived interfaces Key: OAK-1124 URL: https://issues.apache.org/jira/browse/OAK-1124 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela Assignee: Michael Dürig Fix For: 0.15 Attachments: OAK-938.patch OAK-938 only wraps the UserManager; what is required in order to fully reflect the refresh was to also wrap: - Authorizable - User - Group - Impersonation -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (OAK-50) Implement User Management
[ https://issues.apache.org/jira/browse/OAK-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-50. --- Resolution: Fixed Implement User Management - Key: OAK-50 URL: https://issues.apache.org/jira/browse/OAK-50 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: angela Assignee: angela Fix For: 0.15 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (OAK-791) UserManagement: Document changes wrt Jackrabbit 2
[ https://issues.apache.org/jira/browse/OAK-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-791. Resolution: Fixed UserManagement: Document changes wrt Jackrabbit 2 - Key: OAK-791 URL: https://issues.apache.org/jira/browse/OAK-791 Project: Jackrabbit Oak Issue Type: Sub-task Components: jcr Reporter: angela Assignee: angela -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (OAK-1214) Create rep:Unstructured node type for repo internal content
[
https://issues.apache.org/jira/browse/OAK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-1214.
-
Resolution: Fixed
Fix Version/s: 0.15
created the node type at revision 1556767 and modified the token provider
implementation to use this node type instead of nt:unstructured for the root of
the login token nodes
Create rep:Unstructured node type for repo internal content
---
Key: OAK-1214
URL: https://issues.apache.org/jira/browse/OAK-1214
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: angela
Fix For: 0.15
as mentioned earlier on i somehow dislike the idea of using nt:unstructured
for repository internal content like the hidden index and the namespace index
optimization.
therefore i would like suggest to create the following node type:
{code}
rep:Unstructured
- * (UNDEFINED) IGNORE
- * (UNDEFINED) multiple IGNORE
+ * (nt:base) IGNORE (or maybe ABORT would be even better)
{code}
that doesn't limit the creation of any kind of property and child nodes
(except SNSs), doesn't have orderable child nodes and in addition prevents
the subtree to be copied over to the version store in case the parent node is
being made versionable.
wdyt?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (OAK-1180) oak nodetypes should have capital names
[ https://issues.apache.org/jira/browse/OAK-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1180. - Resolution: Fixed Fix Version/s: 0.15 Committed revision 1556800. oak nodetypes should have capital names --- Key: OAK-1180 URL: https://issues.apache.org/jira/browse/OAK-1180 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Tobias Bocanegra Fix For: 0.15 convention is to start all nodetypes with an uppercase letter (like class and interface names): change the following: * oak:Unstructured * oak:NodeType * oak:NamedPropertyDefinitions * oak:PropertyDefinitions * oak:PropertyDefinition * oak:NamedChildNodeDefinitions * oak:ChildNodeDefinitions * oak:ChildNodeDefinition * oak:QueryIndexDefinition -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (OAK-1180) oak nodetypes should have capital names
[ https://issues.apache.org/jira/browse/OAK-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1180: Component/s: core oak nodetypes should have capital names --- Key: OAK-1180 URL: https://issues.apache.org/jira/browse/OAK-1180 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Tobias Bocanegra Fix For: 0.15 convention is to start all nodetypes with an uppercase letter (like class and interface names): change the following: * oak:Unstructured * oak:NodeType * oak:NamedPropertyDefinitions * oak:PropertyDefinitions * oak:PropertyDefinition * oak:NamedChildNodeDefinitions * oak:ChildNodeDefinitions * oak:ChildNodeDefinition * oak:QueryIndexDefinition -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (OAK-1215) Relative property paths don't work in XPath search expressions
[
https://issues.apache.org/jira/browse/OAK-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-1215:
Component/s: query
Relative property paths don't work in XPath search expressions
--
Key: OAK-1215
URL: https://issues.apache.org/jira/browse/OAK-1215
Project: Jackrabbit Oak
Issue Type: Bug
Components: query
Reporter: Jeff Young
Assignee: Thomas Mueller
Priority: Critical
Fix For: 0.15
Attachments: relative-predicate-paths.tiff
A search XPath of the form:
{code}
/jcr:root/etc/commerce/products//*[@size='M' or */@size='M']
{code}
returns:
{code}
Invalid path: *
{code}
(This works fine in Jackrabbit.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1301) Path conditions not respected in XPath query
[
https://issues.apache.org/jira/browse/OAK-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-1301:
Component/s: query
Path conditions not respected in XPath query
Key: OAK-1301
URL: https://issues.apache.org/jira/browse/OAK-1301
Project: Jackrabbit Oak
Issue Type: Bug
Components: query
Affects Versions: 0.13
Reporter: Tobias Bocanegra
Given the following node:
{noformat}
/home/users/testing/socialgraph_test_user_4: {
jcr:primaryType: rep:User,
rep:authorizableId: socialgraph_test_user_4,
social:
{
jcr:primaryType: sling:Folder,
relationships:
{
jcr:primaryType: sling:Folder,
friend:
{
jcr:primaryType: sling:Folder,
socialgraph_test_group:
{
jcr:primaryType: nt:unstructured,
id: socialgraph_test_group
}
}
}
}
}
/home/groups/testing/socialgraph_test_group: {
...
}
{noformat}
and the following query:
{noformat}
/jcr:root/home//social/relationships//*[id='socialgraph_test_group']
{noformat}
does not yield any results. however this query:
{noformat}
/jcr:root/home//*[id='socialgraph_test_group']
{noformat}
returns the following nodes:
{noformat}
/home/users/testing/socialgraph_test_user_4/social/relationships/friend/socialgraph_test_group
/home/groups/testing/socialgraph_test_group
/home/groups/testing/socialgraph_test_group/rep:policy/allow
{noformat}
Although the group nodes don't have the 'id' property.
btw: this used to work as expected in Jackrabbit 2.x
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1267) Failure in ObservationRefreshTest
[ https://issues.apache.org/jira/browse/OAK-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1267: Component/s: jcr Failure in ObservationRefreshTest -- Key: OAK-1267 URL: https://issues.apache.org/jira/browse/OAK-1267 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: angela Assignee: Tobias Bocanegra Failed tests: observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest): added nodes expected:1000 but was:442 Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 106.957 sec FAILURE! observation[3](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest) Time elapsed: 53.047 sec FAILURE! java.lang.AssertionError: added nodes expected:1000 but was:906 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:695) observation[2](org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest) Time elapsed: 58.379 sec FAILURE! java.lang.AssertionError: added nodes expected:1000 but was:396 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.jackrabbit.oak.jcr.observation.ObservationRefreshTest.observation(ObservationRefreshTest.java:119) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
[jira] [Updated] (OAK-1239) RTC: create own artifact (and bundle) for org.apache.jackrabbit.oak.spi
[
https://issues.apache.org/jira/browse/OAK-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-1239:
Component/s: core
RTC: create own artifact (and bundle) for org.apache.jackrabbit.oak.spi
---
Key: OAK-1239
URL: https://issues.apache.org/jira/browse/OAK-1239
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Tobias Bocanegra
Fix For: 0.15
suggest to modularize oak more and create an own artifact (and bundle) for
the {{org.apache.jackrabbit.oak.spi}} package.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1240) RTC: move classes in org.apache.jackrabbit.oak.util to org.apache.jackrabbit.oak.commons
[ https://issues.apache.org/jira/browse/OAK-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1240: Component/s: core commons RTC: move classes in org.apache.jackrabbit.oak.util to org.apache.jackrabbit.oak.commons Key: OAK-1240 URL: https://issues.apache.org/jira/browse/OAK-1240 Project: Jackrabbit Oak Issue Type: Improvement Components: commons, core Reporter: Tobias Bocanegra Fix For: 0.15 oajo.commons and oajo.utils seem to server the same purpose. if so, we should move the utils to commons (or vice versa). if not we should justify and document the existence of those. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OAK-1239) RTC: create own artifact (and bundle) for org.apache.jackrabbit.oak.spi
[
https://issues.apache.org/jira/browse/OAK-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13866634#comment-13866634
]
angela commented on OAK-1239:
-
fine with me
RTC: create own artifact (and bundle) for org.apache.jackrabbit.oak.spi
---
Key: OAK-1239
URL: https://issues.apache.org/jira/browse/OAK-1239
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Tobias Bocanegra
Fix For: 0.15
suggest to modularize oak more and create an own artifact (and bundle) for
the {{org.apache.jackrabbit.oak.spi}} package.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1193) AbstractTree.getChildNodeCount() should not actively filter out hidden names
[
https://issues.apache.org/jira/browse/OAK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-1193:
Component/s: core
AbstractTree.getChildNodeCount() should not actively filter out hidden names
Key: OAK-1193
URL: https://issues.apache.org/jira/browse/OAK-1193
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Tobias Bocanegra
{code}
long count = nodeBuilder.getChildNodeCount(max);
if (count 0) {
for (String name : INTERNAL_NODE_NAMES) {
if (nodeBuilder.hasChildNode(name)) {
count--;
}
}
}
{code}
Checks {{INTERNAL_NODE_NAMES}} which is slow and not extensible. it should
propagate the hidden-filtering down to node builder.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1238) RTC: create own artifact (and bundle) for org.apache.jackrabbit.oak.api
[
https://issues.apache.org/jira/browse/OAK-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-1238:
Component/s: core
RTC: create own artifact (and bundle) for org.apache.jackrabbit.oak.api
---
Key: OAK-1238
URL: https://issues.apache.org/jira/browse/OAK-1238
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: Tobias Bocanegra
Fix For: 0.15
suggest to modularize oak more and create an own artifact (and bundle) for
the {{org.apache.jackrabbit.oak.api}} package.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (OAK-1311) Permission Cache causes non-deterministic access control test failures
[ https://issues.apache.org/jira/browse/OAK-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1311: Component/s: core Permission Cache causes non-deterministic access control test failures -- Key: OAK-1311 URL: https://issues.apache.org/jira/browse/OAK-1311 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (OAK-1206) Consider renaming internal nodetypes and item names
[ https://issues.apache.org/jira/browse/OAK-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1206: Component/s: core Consider renaming internal nodetypes and item names --- Key: OAK-1206 URL: https://issues.apache.org/jira/browse/OAK-1206 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Tobias Bocanegra some new nodetypes have the oak namespace but are used only internally. in jackrabbit 2.x we used the 'internal' namespace for those. I suggest to use the internal namespace for nodes that are not (or should not) be created via JCR, namely: * rep:NodeType * rep:NamedPropertyDefinitions * rep:PropertyDefinitions * rep:PropertyDefinition * rep:NamedChildNodeDefinitions * rep:ChildNodeDefinitions * rep:ChildNodeDefinition see also OAK-1180 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OAK-1206) Consider renaming internal nodetypes and item names
[ https://issues.apache.org/jira/browse/OAK-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13866697#comment-13866697 ] angela commented on OAK-1206: - Committed revision 1556828: adjusted internal node type and item names for the internal node type and the namespace storage Consider renaming internal nodetypes and item names --- Key: OAK-1206 URL: https://issues.apache.org/jira/browse/OAK-1206 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Tobias Bocanegra Fix For: 0.15 some new nodetypes have the oak namespace but are used only internally. in jackrabbit 2.x we used the 'internal' namespace for those. I suggest to use the internal namespace for nodes that are not (or should not) be created via JCR, namely: * rep:NodeType * rep:NamedPropertyDefinitions * rep:PropertyDefinitions * rep:PropertyDefinition * rep:NamedChildNodeDefinitions * rep:ChildNodeDefinitions * rep:ChildNodeDefinition see also OAK-1180 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (OAK-1316) AnnotatingConflictHandler does not set primary type of rep:ours nodes
angela created OAK-1316: --- Summary: AnnotatingConflictHandler does not set primary type of rep:ours nodes Key: OAK-1316 URL: https://issues.apache.org/jira/browse/OAK-1316 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela from what i can see the rep:ours nodes don't get a primary type set during creation in the AnnotatingConflictHandler. while addressing i would also change the required primary type to rep:Unstructured instead of nt:unstructured. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (OAK-917) Container: Issues with Workspace#copy and Root#copy
[ https://issues.apache.org/jira/browse/OAK-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-917: --- Fix Version/s: 1.0 Container: Issues with Workspace#copy and Root#copy --- Key: OAK-917 URL: https://issues.apache.org/jira/browse/OAK-917 Project: Jackrabbit Oak Issue Type: Task Components: core, jcr Reporter: angela Fix For: 1.0 container issue to collect issues with the current implementation of Workspace#copy: - missing UUID generation - no version history generated for versionable nodes - no handling for locks present on copied nodes -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (OAK-1316) AnnotatingConflictHandler does not set primary type of rep:ours nodes
[ https://issues.apache.org/jira/browse/OAK-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-1316. - Resolution: Fixed Fix Version/s: 0.15 Committed revision 1556847. AnnotatingConflictHandler does not set primary type of rep:ours nodes - Key: OAK-1316 URL: https://issues.apache.org/jira/browse/OAK-1316 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: angela Assignee: angela Fix For: 0.15 from what i can see the rep:ours nodes don't get a primary type set during creation in the AnnotatingConflictHandler. while addressing i would also change the required primary type to rep:Unstructured instead of nt:unstructured. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (OAK-942) Permissions: Document changes wrt Jackrabbit
[ https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-942: --- Fix Version/s: 1.0 Permissions: Document changes wrt Jackrabbit Key: OAK-942 URL: https://issues.apache.org/jira/browse/OAK-942 Project: Jackrabbit Oak Issue Type: Sub-task Components: doc Reporter: angela Assignee: angela Fix For: 1.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (OAK-1311) Permission Cache causes non-deterministic access control test failures
[ https://issues.apache.org/jira/browse/OAK-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-1311: Fix Version/s: 0.15 Permission Cache causes non-deterministic access control test failures -- Key: OAK-1311 URL: https://issues.apache.org/jira/browse/OAK-1311 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Tobias Bocanegra Assignee: Tobias Bocanegra Fix For: 0.15 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OAK-1291) RandomizedReadTest fails with OutOfMemoryError: PermGen space
[
https://issues.apache.org/jira/browse/OAK-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13867621#comment-13867621
]
angela commented on OAK-1291:
-
note, that it might also be that i introduced some sort of problem while
refactoring the original code; thanks for looking at it, very much appreciated.
RandomizedReadTest fails with OutOfMemoryError: PermGen space
-
Key: OAK-1291
URL: https://issues.apache.org/jira/browse/OAK-1291
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Reporter: Michael Dürig
Labels: test
This happened while running the maven build with {{-PintegrationTesting}}:
{code}
Running org.apache.jackrabbit.oak.jcr.random.RandomizedReadTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.418 sec
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
Exception in thread main java.lang.OutOfMemoryError: PermGen space
Results :
Tests run: 722, Failures: 0, Errors: 0, Skipped: 48
{code}
The crucial point being Surefire silently ignoring the following tests such
that the build happily succeeds making following failures. Note, that test
suite consists of 2003 tests in contrast to the 722 reported by Surefire.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (OAK-1181) Review node type definition for oak:queryIndexDefinition
[
https://issues.apache.org/jira/browse/OAK-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-1181.
-
Resolution: Fixed
ok... i made 2 minor modifications to the node type definition:
a) naming convention
b) extending from oak:Unstructured
Review node type definition for oak:queryIndexDefinition
Key: OAK-1181
URL: https://issues.apache.org/jira/browse/OAK-1181
Project: Jackrabbit Oak
Issue Type: Sub-task
Components: core
Reporter: angela
Assignee: angela
Fix For: 0.15
current definition:
{noformat}
[oak:queryIndexDefinition] nt:unstructured
- type (STRING) mandatory
- async (STRING)
- reindex (BOOLEAN) mandatory IGNORE
{noformat}
things to review:
- name not following naming convention
- extending from nt:unstructured
- OPV flags (behavior upon versioning of the parent node)
- incomplete list of properties compared to those mentioned in query.md
- 'async' property is string with a predefined value 'async': why not boolean?
- index content stored underneath the definition has not dedicated node type.
things to consider:
- is it expected that an index definition has custom properties?
- is it expected that such custom properties have other property types that
STRING/NAME/BOOLEAN? e.g. a binary?
- is it expected that an index definition has other child nodes that the
index content itself?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
