[
https://issues.apache.org/jira/browse/OAK-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653213#comment-14653213
]
Thomas Mueller commented on OAK-3169:
-------------------------------------
> in the meantime I managed to install an IBM JVM on my system (IBM eclipse
> tools download contains it); the unit tests that we currently have do not
> fail though.
Please note it also depends on the version of the JVM. In the Oracle JVM for
example, the iteration order of a HashMap changed in some version (1.6 I
think), and may have changed again. It is quite likely it also changed in an
IBM JVM.
> Changing the signature of such a central component at this stage is asking
> for trouble.
Sure. Backward compatibility is a problem, and it's quite a lot of work to
change all the code that uses this.
> If the Javadoc is not clear enough about the semantics of the return value we
> should change change that.
Yes, the Javadocs need to be improved.
We should review all the code that uses this "Diff" mechanism. It's possible
that there are more places were we return the wrong value in some cases, and
(as we have seen here) this goes undetected quite easily.
> 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
> Affects Versions: 1.2.3, 1.0.18
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 1.2.4, 1.3.5, 1.0.19
>
>
> 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)
