Randall Hauch created JCR-3326:
----------------------------------
Summary: VersionManager.restore(String,String,boolean) does not
adhere to specification
Key: JCR-3326
URL: https://issues.apache.org/jira/browse/JCR-3326
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.4.1
Reporter: Randall Hauch
Fix For: 2.5.1, 2.6
The JCR 2.0 specification changed slightly the behavior of restoring a node
when a versionable child already exists in the workspace and the
'removeExisting' flag is true. Specifically, Section 15.7.5 states:
"If the workspace currently has an already existing node corresponding to
C's version history and the removeExisting
flag of the restore is set to true, then that instance of C becomes the
child of the restored N."
Jackrabbit's implementation of VersionManager.restore(String path, String
version, boolean removeExisting) does not correctly implement this behavior.
This was likely not identified because the corresponding TCK test was
incorrectly checking for the JCR 1.0 behavior (see JCR-2666 for details).
JCR 2.0 added this method to replace the now-deprecated the
javax.jcr.Node.restore(String,boolean) method, but both are still expected to
have the same behavior. Interestingly, Jackrabbit's implementation of the
now-deprecated Node.restore(String,boolean) method was changed to reflect the
newer JCR 2.0 behavior, and the corresponding TCK test for the Node-based
method was also changed to check for the new behavior.
--
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