jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Hauch (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3326) VersionManager.restore(String,String,boolean) does not adhere to specification
Date Thu, 31 May 2012 15:21:24 GMT

    [ 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

        

Mime
View raw message