[ 
https://issues.apache.org/jira/browse/OAK-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated OAK-709:
------------------------------

    Attachment: 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch

Final version of the NodeState.exists() patch. Now the full 
-PintegrationTesting build passes.

bq. updated patch for the SecureNodeState

Nice! We're definitely making progress here.

Re: TODO on getChildNode(); the exists() patch adjusts the {{getChildNode()}} 
contract to never return null. Instead a missing (or read-protected) child node 
is represented by a "non-existent" {{NodeState}} instance whose {{exists()}} 
method returns {{false}}.

Here's what I write about this change in the NodeState javadocs:

{code}
 * <h2>Existence and iterability of node states</h2>
 * <p>
 * The {@link #getChildNode(String)} method is special in that it
 * <em>never</em> returns a {@code null} value, even if the named child
 * node does not exist. Instead a client should use the {@link #exists()}
 * method on the returned child state to check whether that node exists.
 * The purpose of this separation of concerns is to allow an implementation
 * to lazily load content only when it's actually read instead of just
 * traversed. It also simplifies client code by avoiding the need for many
 * {@code null} checks when traversing paths.
 * <p>
 * The <em>iterability</em> of a node is a related concept to the
 * above-mentioned existence. A node state is <em>iterable</em> if it
 * is included in the return values of the {@link #getChildNodeCount()},
 * {@link #getChildNodeNames()} and {@link #getChildNodeEntries()} methods.
 * An iterable node is guaranteed to exist, though not all existing nodes
 * are necessarily iterable.
 * <p>
 * Furthermore, a non-existing node is guaranteed to contain no properties
 * or iterable child nodes. It can, however contain non-iterable children.
 * Such scenarios are typically the result of access control restrictions.
{code}
                
> Consider moving permission evaluation to the node state level
> -------------------------------------------------------------
>
>                 Key: OAK-709
>                 URL: https://issues.apache.org/jira/browse/OAK-709
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: core
>            Reporter: angela
>         Attachments: 
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch, 
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch, 
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch, 
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch, 
> OAK-709.patch, SecureNodeState.java
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to