Incorrect OnParentVersion behavior

When checking in a node (or subgraph), ModeShape does not properly handle the OnParentVersion (OPV) behavior of the properties and children of a versionable node. This error was pointed out by sjahan in the ModeShape forums.

The basic problem is this: JcrVersionManager's checkin method has the following code:

final int onParentVersion = node.getDefinition().getOnParentVersion();
...
for (NodeIterator childNodes = node.getNodes(); childNodes.hasNext();) {
    AbstractJcrNode childNode = (AbstractJcrNode)childNodes.nextNode();
    versionNodeAt(childNode, frozenVersionPath, systemBatch, onParentVersion);
}

This code is using the OPV of the node being checked in (that is the OPV of the child node definition for this node, where that child node definition belongs to the primary type or mixin types of the node's parent) to determine how/whether the child nodes should be versioned. This is not correct, because how/whether a node is versioned depends upon its own OPV value of the child node definition that applies to it, not its parent's OPV.

Strictly speaking, it is more complicated than this. If a child node has an OPV of "COPY", then per Section 3.13.9 item 5 of the JSR-283 specification applies. If node N is the node being checked in, then (emphasis added):

For each child node C of N where

• C has an OPV of COPY,

a copy of the entire subgraph rooted at C (regardless of the OPV values of the sub-items) is added to the frozen node, preserving the name of C and the names and values of all its sub-items.

That means that whenever the OPV of a child node is 'COPY', then all properties and children should be versioned as if they all had 'COPY' OPV, regardless of what their OPV actually is. Similarly, item 6 of the same JSR-283 specification dictates the behavior for an OPV of 'VERSION' (emphasis added):

For each child node C of N where:

• C has an OPV of VERSION

Under simple versioning, the same behavior as COPY.

Under full versioning, if C is not mix:versionable, the same behavior as COPY.

Under full versioning, if C is mix:versionable, then a special nt:versionedChild node with a reference to the version history of C is substituted in place of C as a child of the frozen node.

Thus, in addition to using the child node's OPV in the 'checkin' method (as described above), we need to slightly modify how the 'versionNodeAt' method is implemented to exhibit the correct COPY behavior.