You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (Created) (JIRA)" <ji...@apache.org> on 2011/10/14 15:36:11 UTC
[jira] [Created] (JCR-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
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
Priority: Minor
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
[jira] [Resolved] (JCR-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke resolved JCR-3115.
---------------------------------
Resolution: Fixed
Fix Version/s: 2.3.2
2.2.10
trunk: 1185691 and 1185692 (test case)
2.2: 1185711
> 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 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-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132687#comment-13132687 ]
Julian Reschke commented on JCR-3115:
-------------------------------------
Modify checker to also inspect "candidate" version histories (trunk: 1187344, 2.2: 1187345). Test case (trunk only): 1187354.
> 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 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-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127547#comment-13127547 ]
Julian Reschke commented on JCR-3115:
-------------------------------------
A possible approach to work-around this issue would be to change the version cleanup to move the broken history to a different path.
> 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
> Priority: Minor
> Attachments: AutoFixCorruptNode.java
>
>
> 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
[jira] [Assigned] (JCR-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke reassigned JCR-3115:
-----------------------------------
Assignee: Julian Reschke
> 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
>
>
> 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
[jira] [Updated] (JCR-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3115:
--------------------------------
Attachment: JCR-3115.patch
> 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
[jira] [Commented] (JCR-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (JCR-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128922#comment-13128922 ]
Julian Reschke commented on JCR-3115:
-------------------------------------
r1185228: added test case for breaking and fixing version storage (also add hook for running consistency check in "fix" mode)
So at least some types of broken versioning PM can be fixed by the bundle consistency check sufficiently to reenable versioning.
> 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
>
>
> 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
[jira] [Commented] (JCR-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13130728#comment-13130728 ]
Julian Reschke commented on JCR-3115:
-------------------------------------
Additional fix in trunk (r1186285) and 2.2 (r1186294).
> 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 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-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3115:
--------------------------------
Attachment: JCR-3115.patch
1) adds test case
2) augments InconsistentVersioningState with information about the VHR's nodeId
3) enables RepositoryChecker to rename the VHR in place
> 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
>
>
> 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
[jira] [Commented] (JCR-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129701#comment-13129701 ]
Jukka Zitting commented on JCR-3115:
------------------------------------
Looks good in general. Some comments in decreasing order of importance:
* 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.
* Can we make all InconsistentVersioningState instances carry the version history ID? I'd remove all the constructors without the ID argument.
* Instead of the instanceof InternalVersionManagerImpl check, I'd rather simply change the RepositoryChecker constructor to always take a InternalVersionManagerImpl instance.
* Instead of the instanceof InconsistentVersioningState check, I'd have a separate catch block for such exceptions.
* IIRC Calendar.getInstance() should already reflect the current time. No need for the setTimeInMillis(System.currentTimeMillis()) call.
* The e.printStackTrace() call should be dropped.
> 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
>
>
> 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
[jira] [Updated] (JCR-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3115:
--------------------------------
Attachment: JCR-3115.patch
Updated patch: exception cleaned up, new constructor used in more places, RepositoryChecker extended so the VHR renaming occurs in more situations
> 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
>
>
> 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
[jira] [Commented] (JCR-3115) Versioning fixup leaves persistence
in a state where the node can't be made versionable again
Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131649#comment-13131649 ]
Julian Reschke commented on JCR-3115:
-------------------------------------
Changed RepositoryChecker to obtain the VersionHistoryInfo first, in order to match more closely what other components do when enabling versioning (trunk: 1186802, 2.2: 1186294)
> 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 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-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3115:
--------------------------------
Attachment: JCR-3115.patch
> 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
>
>
> 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
[jira] [Updated] (JCR-3115) Versioning fixup leaves persistence in
a state where the node can't be made versionable again
Posted by "Julian Reschke (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCR-3115:
--------------------------------
Attachment: AutoFixCorruptNode.java
w-i-p test case, based on Alex' earlier work.
> 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
> Priority: Minor
> Attachments: AutoFixCorruptNode.java
>
>
> 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