jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Created] (OAK-275) Introduce TreeLocation interface
Date Thu, 23 Aug 2012 12:41:43 GMT
Michael Dürig created OAK-275:

             Summary: Introduce TreeLocation interface
                 Key: OAK-275
                 URL: https://issues.apache.org/jira/browse/OAK-275
             Project: Jackrabbit Oak
          Issue Type: Improvement
          Components: core
            Reporter: Michael Dürig

In order to address the issues revolving around access control (i.e OAK-212, OAK-214, OAK-218,
OAK-220, OAK-226,...) I'd like to introduce a new interface {{TreeLocation}}: 

 * A {@code TreeLocation} denotes a location inside a tree.
 * It can either refer to a inner node (that is a {@link org.apache.jackrabbit.oak.api.Tree})
 * or to a leaf (that is a {@link org.apache.jackrabbit.oak.api.PropertyState}).
 * {@code TreeLocation} instances provide methods for navigating trees. {@code TreeLocation}
 * instances are immutable and navigating a tree always results in new {@code TreeLocation}
 * instances. Navigation never fails. Errors are deferred until the underlying item itself
 * accessed. That is, if a {@code TreeLocation} points to an item which does not exist or
 * is unavailable otherwise (i.e. due to access control restrictions) accessing the tree
 * will return {@code null} at this point.
public interface TreeLocation {

     * Navigate to the parent
     * @return  a {@code TreeLocation} for the parent of this location.
    TreeLocation getParent();

     * Navigate to a child
     * @param name  name of the child
     * @return  a {@code TreeLocation} for a child with the given {@code name}.
    TreeLocation getChild(String name);

     * Get the underlying {@link org.apache.jackrabbit.oak.api.Tree} for this {@code TreeLocation}.
     * @return  underlying {@code Tree} instance or {@code null} if not available.
    Tree getTree();

     * Get the underlying {@link org.apache.jackrabbit.oak.api.PropertyState} for this {@code
     * @return  underlying {@code PropertyState} instance or {@code null} if not available.
    PropertyState getProperty();

Such an interface would decouple navigation from the tree itself while at the same time unifying
node and property access. This allows us to enforce access control restriction on the tree
itself while still being able to access items which we are "unlinked" by access control restrictions.
In addition unification of node and property access will simplify the code in many places.
Finally {{TreeLocations}} might better encapsulate the resolution of a location in a tree
to the actual tree. This is something which currently done in {{Node/PropertyDelegate.resolve}}
but always bothered me as too ad-hoc.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message