[
https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15903601#comment-15903601
]
Julian Reschke commented on JCR-3115:
-------------------------------------
trunk: [r1187345|http://svn.apache.org/r1187345]
[r1187344|http://svn.apache.org/r1187344]
[r1186802|http://svn.apache.org/r1186802]
[r1186285|http://svn.apache.org/r1186285]
[r1185692|http://svn.apache.org/r1185692]
[r1185691|http://svn.apache.org/r1185691]
[r1185228|http://svn.apache.org/r1185228]
> 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
> Fix For: 2.2.10, 2.3.2
>
> 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 was sent by Atlassian JIRA
(v6.3.15#6346)
