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] [Comment Edited] (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=14647707#comment-14647707
] 

angela edited comment on OAK-3169 at 7/30/15 2:44 PM:
------------------------------------------------------

[~tmueller], thanks for spotting. as far as test-cases are concerned: at the Oak level there
are quite some security related tests that create hidden {{Tree}}. so, that should be feasible
if the default security setup is used later on to run the test, which adds a node with {{mix:versionable}}
to trigger the {{VersionablePathHook}}. 


was (Author: anchela):
[~tmueller], thanks for spotting. as far as test-cases are concerned: at the Oak level there
are quite some security related tests that create hidden {{Tree}}s. so, that should be feasible
if the default security setup is used later on to run the test, which adds a node with {{mix:versionable}}
to trigger the {{VersionablePathHook}}. 

> 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