[jira] [Comment Edited] (OAK-709) Consider moving permission evaluation to the node state level

["Jukka Zitting (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622105#comment-13622105 ] 

Jukka Zitting edited comment on OAK-709 at 4/4/13 12:46 PM:
------------------------------------------------------------

Final version of the NodeState.exists() patch (see also https://github.com/jukka/jackrabbit-oak/commit/f698f968eca44766f1f3d84426021b16e54f2e19). Now the -PintegrationTesting build passes except for some issue in oak-solr-embedded. I'll look into it.

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}
                
      was (Author: jukkaz):
    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