You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Randall Hauch (JIRA)" <ji...@apache.org> on 2012/05/31 17:19:22 UTC
[jira] [Created] (JCR-3326)
VersionManager.restore(String,String,boolean) does not adhere to
specification
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
[jira] [Commented] (JCR-3326)
VersionManager.restore(String,String,boolean) does not adhere to
specification
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413750#comment-13413750 ]
Julian Reschke commented on JCR-3326:
-------------------------------------
I suspect a test fixture problem; even duplicating the test code for testRestoreName leads to a test failure.
> 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
> Assignee: Julian Reschke
> 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
[jira] [Resolved] (JCR-3326) missing test configuration for
org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2()
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke resolved JCR-3326.
---------------------------------
Resolution: Fixed
> missing test configuration for org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2()
> -------------------------------------------------------------------------------------------------------
>
> Key: JCR-3326
> URL: https://issues.apache.org/jira/browse/JCR-3326
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Randall Hauch
> Assignee: Julian Reschke
> Priority: Trivial
> Fix For: 2.6
>
>
> The test config for the above mentioned test case was missing, causing the test to fail now it has been fixed for JCR-2666.
--
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
[jira] [Commented] (JCR-3326)
VersionManager.restore(String,String,boolean) does not adhere to
specification
Posted by "Randall Hauch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286647#comment-13286647 ]
Randall Hauch commented on JCR-3326:
------------------------------------
Not sure if I was supposed to set the Fix Version(s), so I took a swag at them. Please adjust/correct as necessary.
> 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
[jira] [Updated] (JCR-3326) missing test configration for
org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2()
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3326:
--------------------------------
Description: The test config for the above mentioned test case was missing, causing the test to fail now it has been fixed for JCR-2666. (was: 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.)
Priority: Trivial (was: Major)
Affects Version/s: (was: 2.4.1)
Fix Version/s: (was: 2.5.1)
Summary: missing test configration for org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2() (was: VersionManager.restore(String,String,boolean) does not adhere to specification)
> missing test configration for org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2()
> ------------------------------------------------------------------------------------------------------
>
> Key: JCR-3326
> URL: https://issues.apache.org/jira/browse/JCR-3326
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Randall Hauch
> Assignee: Julian Reschke
> Priority: Trivial
> Fix For: 2.6
>
>
> The test config for the above mentioned test case was missing, causing the test to fail now it has been fixed for JCR-2666.
--
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
[jira] [Updated] (JCR-3326) missing test configuration for
org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2()
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3326:
--------------------------------
Summary: missing test configuration for org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2() (was: missing test configration for org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2())
> missing test configuration for org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreNameJcr2()
> -------------------------------------------------------------------------------------------------------
>
> Key: JCR-3326
> URL: https://issues.apache.org/jira/browse/JCR-3326
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Randall Hauch
> Assignee: Julian Reschke
> Priority: Trivial
> Fix For: 2.6
>
>
> The test config for the above mentioned test case was missing, causing the test to fail now it has been fixed for JCR-2666.
--
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
[jira] [Assigned] (JCR-3326)
VersionManager.restore(String,String,boolean) does not adhere to
specification
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke reassigned JCR-3326:
-----------------------------------
Assignee: Julian Reschke
> 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
> Assignee: Julian Reschke
> 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