jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3169) rep:versionablePaths mixin not always set for versionable nodes
Date Thu, 30 Jul 2015 14:44:04 GMT

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

angela commented on OAK-3169:
-----------------------------

one more thing: there might be other areas in the commit that suffer from the a similar problem....
you definitely don't want to traverse into the tree defined by the hidden node during this
commithook...

> rep:versionablePaths mixin not always set for versionable nodes
> ---------------------------------------------------------------
>
>                 Key: OAK-3169
>                 URL: https://issues.apache.org/jira/browse/OAK-3169
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>             Fix For: 1.4, 1.2.4, 1.3.4, 1.0.18
>
>
> For versionable nodes, the "rep:VersionablePaths" mixin and the "\{workspaceName\}" property
is sometimes not set.
> The problem seems to be that VersionablePathHook terminates processing too early if it
encounters a hidden node:
> {noformat}
> public boolean childNodeChanged(String name, NodeState before, NodeState after) {
>     if (NodeStateUtils.isHidden(name)) {
>         // stop comparison
>         return false;  /// <<<<< bug
>     }
>     ....
> }
> {noformat}
> Because the method returns false, processing is completely stopped, that includes processing
of sibling nodes and further processing on any parent node.
> The bugfix seems to be "return true" instead of "return false".
> Remark: It's quite easy to make this mistake. Maybe we should consider changing NodeStateDiff,
and get rid of the return value for this method (change all methods of NodeStateDiff to void).
For the "stop any further processing" case, we could use fast exception handling for flow
control, for example:
> {noformat}
> public interface NodeStateDiff {
>     // throw this exception to stop any further processing
>     Exception STOP_PROCESSING = new Exception();
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message