jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3115) Versioning fixup leaves persistence in a state where the node can't be made versionable again
Date Tue, 18 Oct 2011 13:44:10 GMT

    [ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129738#comment-13129738
] 

Julian Reschke commented on JCR-3115:
-------------------------------------

> What happens if there are more than one children of a given version history parent need
to be renamed? The current code seems to always generate a new modified parent node state.

Now re-using state from ChangeLog when present (please have a look)

> Can we make all InconsistentVersioningState instances carry the version history ID? I'd
remove all the constructors without the ID argument.

Not all of them; for instance we throw it when the VH node is missing in which case we do
not have a ID :-).

> Instead of the instanceof InternalVersionManagerImpl check, I'd rather simply change
the RepositoryChecker constructor to always take a InternalVersionManagerImpl instance.

Done.

> Instead of the instanceof InconsistentVersioningState check, I'd have a separate catch
block for such exceptions.

Done.

>  IIRC Calendar.getInstance() should already reflect the current time. No need for the
setTimeInMillis(System.currentTimeMillis()) call.

Done.

> The e.printStackTrace() call should be dropped. 

Was duplicated from existing code. Refactored to avoid code duplication.

Also now uses the proper nodeId for renaming (the node's ID, not the VH's ID), and tests that.
                
> Versioning fixup leaves persistence in a state where the node can't be made versionable
again
> ---------------------------------------------------------------------------------------------
>
>                 Key: JCR-3115
>                 URL: https://issues.apache.org/jira/browse/JCR-3115
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, versioning
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>            Priority: Minor
>         Attachments: AutoFixCorruptNode.java, JCR-3115.patch, JCR-3115.patch, JCR-3115.patch,
JCR-3115.patch
>
>
> Jackrabbit's version recovery mode (org.apache.jackrabbit.version.recovery system property)
disconnects all version histories that expose problems that manifest in unexpected exceptions
being thrown. "disconnects" means removing the properties defined for mix:versionable and
removing the mixin type. The actual versioning related nodes remain in place.
> The problem: when re-adding mix:versionable, ItemSaveOperation.initVersionHistories tries
to create the new version history in the same location (the path being derived from the versionable
node's identifier), and consequently fails because of the broken underlying storage.
> (attaching a work-in-progress test case that illustrates the problem)

--
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