[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Toper updated JCR-556: -- Attachment: VisitorPattern22022007.patch Hello, Thanks for your comment. VisitorPattern22022007.patch implements nearly all of your remarks. I didn't change the code flow. IMO both ways has drawbacks. I feel the code is still clear because it is really simple. Since it is easy to fix later, I propose to do it later if we feel the need. Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch, VisitorPattern22022007.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Toper updated JCR-556: -- Attachment: VisitorPattern22022007-2.patch VisitorPattern22022007-2.patch is checkstyle compliant. Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch, VisitorPattern22022007-2.patch, VisitorPattern22022007.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475018 ] Nicolas Toper commented on JCR-556: --- Stefan, You are right. It is more elegant. I'll update the code and rewrite Javadoc parts. Thanks Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch, VisitorPattern22022007-2.patch, VisitorPattern22022007.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Toper updated JCR-556: -- Attachment: VisitorPattern22022007-3.patch VisitorPattern22022007-3.patch implements all the required updates. My visitor class visits all the states with it. Thank you very much for your remark. Unless you see anything else, I will now finish the backup and restore code which use the Visitor. Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch, VisitorPattern22022007-2.patch, VisitorPattern22022007-3.patch, VisitorPattern22022007.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475049 ] Nicolas Toper commented on JCR-556: --- Yes my mistake. Why don't you want to check for initialization of the persistence manager? Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch, VisitorPattern22022007-2.patch, VisitorPattern22022007-3.patch, VisitorPattern22022007.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Toper updated JCR-556: -- Attachment: Visitor2202007-final.patch Hi, Here is the patch with Stefan's suggestion and tested it. I have also updated my SQL requests so they could work with Stefan's code. Thanks a lot for your help Stefan and Jukka! Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, Visitor2202007-final.patch, VisitorPattern200207.patch, VisitorPattern22022007-2.patch, VisitorPattern22022007-3.patch, VisitorPattern22022007.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Toper updated JCR-556: -- Attachment: VisitorPattern200207.patch Hi, I still haven't quit working on the backup tool. Thanks to Jukka, I have found a much easier solution to backup the workspace content: work at the persistence manager level directly. But to achieve this idea, I had to write a Visitor pattern to the PersistenceManager system. I needed a fast iteration on all nodes in order to backup them with a small memory footprint (restore can take longer so it is less of an issue). I couldn't reuse the Visitor facilities provided by the JCR API since I need to work at a much lower level. This is the patch I now propose to the Jackrabbit community. It is composed of 3 files: - ItemStateVisitor is an interface. A visitor of an ItemState must implement it - VisitableItemStateCollection is an interface. Every class implementing this interface can be visited by an ItemStateVisitor. (Those classes are more general than - A patch to DatabasePersistenceManager implementing VisitableItemStateCollection. With it most repository are backup ready. It will be used also as a proof of concept code for other contributors who might want to implement the visitor interface to others peristence manager. If this patch is accepted, I will finish working on the backup/restore method of the backup tool (those are the last steps) and add a fallback code so all repository can be backuped albeit in a slower way. BR, Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=all ] Nicolas Toper updated JCR-535: -- Attachment: WorkspaceImporterRootNodeTest.patch Hi, Here is a test code demonstrating the issue and that it applies only to REPLACE_EXISTING behaviour. Nicolas Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt, patch-WorkspaceImporter-231006-2.txt, patch-WorkspaceImporter-231006.txt, patch-WorkspaceImporterTest-231006.txt, WorkspaceImporterRootNodeTest.patch When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12444926 ] Nicolas Toper commented on JCR-535: --- Hi, About this issue, can I assume there are no concurrent operations? I am deleting all subnodes under root except jcr:system. The issue I see is a session creating some nodes while I delete them all. I think this could happen and this should be taken care of. Are my assumptions correct? If yes, how could I manage to handle this issue? Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt, patch-WorkspaceImporter-231006-2.txt, patch-WorkspaceImporter-231006.txt, patch-WorkspaceImporterTest-231006.txt When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12444311 ] Nicolas Toper commented on JCR-535: --- Sure. Let me write it. I'll post it this week. Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt, patch-WorkspaceImporter-231006-2.txt, patch-WorkspaceImporter-231006.txt, patch-WorkspaceImporterTest-231006.txt When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=comments#action_12444079 ] Nicolas Toper commented on JCR-556: --- Hi, For those wondering, what is the status of the backup tool. It is working, but to make it really useful, Jukka and I are integrating it more closely to the core. We are also using this opportunity to fix a few issues. Please find here the list of the remaining tasks (some done and undone): - WorkspaceImporter refactoring (to avoid code duplicate): OK - Close JCR 535: waiting for commitment - new PropInfo: waiting for commitment (Flags inserted: see relevant JIRA issue) - BatchedItemOperations: waiting for commitment (Flags inserted: see relevant JIRA issue) - new set of test of the backup tool (to detect possible new issues and dependencies) - Add a raw parameter to the Importer (no postProcess node: no version history creation and so on) - setBatchedItemOperations: in WorkspaceImporter or in an inherited class? (used to import versioning) - versionManager: importVersions (can call a specific Importer if needed but find a way to get rid of the specific NodeVersionsHistoriesStateManager). We are nearly done :) I hope to close this project before the end of the month, if Jukka has enough time to review and integrate my patches. BR, Nico my blog! http://www.deviant-abstraction.net !! Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12444114 ] Nicolas Toper commented on JCR-535: --- My mistakes. Sorry. It was caused by my first try to get rid of the bug. I will correct them ASAP. About the test case, where should I write it? As WorkspaceImporterTest in Core? (I used the backup tool unit test to check the correct behaviour). Let me rework it before looking at it :) Nico Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt, patch-WorkspaceImporter-231006.txt When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=all ] Nicolas Toper updated JCR-535: -- Attachment: patch-WorkspaceImporter-231006-2.txt Here is the new patch. Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt, patch-WorkspaceImporter-231006-2.txt, patch-WorkspaceImporter-231006.txt When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-535) Ignore root node when importing through sysView
[ http://issues.apache.org/jira/browse/JCR-535?page=comments#action_12443580 ] Nicolas Toper commented on JCR-535: --- Understood :) Thanks. So I'll check the UUID (imagine a use case where we swap one JCR compliant repository for another; if I remind the spec correctly the root node UUID can be different in both repository). One issue is still unclear: do I delete simply all nodes in the subtree? What about protected nodes? (/jcr:system will be explicitely excluded from the removal of course) Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-569) WorkspaceImporter Refactoring
[ http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12442223 ] Nicolas Toper commented on JCR-569: --- [[ Old comment, sent by email on Wed, 13 Sep 2006 18:00:23 +0200 ]] Hi Stefan, About your first point, you are right: this is why I sent yesterday a more in depth analysis. This JIRA issue will be used as Jukka suggested it, for refactoring issue of this class only. I would like to create two classes: one generic Importer (name to be defined) and one dedicated to import a workspace. I would use the generic Importer for the backup and others could use it when they need to batch load some data (of course, it is more complex to use and set up). The WorkspaceImporter would be used for the same use case as now. The WorkspaceImporter constructor would stay the same to avoid backward compatibility issue. Here is a quick descriptive of each methods of the generic Importer. They are private since no other class need them (this class is used with the ContentHandler). private boolean checkNode(NodeInfo nodeInfo) Check if the node can be imported to the repository. For instance, it can try to delete a protected node, the same node might already exist (it can depend on the ImportUUIDBehavior used) or the node can be incorrect according to the node type in the repository. Some checks are escaped if raw mode is chosen. If the node is not correct, it puts the skip mode on true to exclude this subtree. When the subtree is over, the skip mode is put to off. If the error is serious (constraint issue for instance), an exception will be thrown. private NodeState createNode(NodeState parent, NodeInfo nodeInfo) Create the NodeState depending according to ImportUUIDBehavior flag private void createProperties(NodeState myNode, List propInfos) Create the properties depending according to ImportUUIDBehavior flag private boolean isSkipped(NodeInfo nodeInfo) if we are in skip mode return true; else false. private void postProcess(NodeState node) Initialize if raw == false, this method is not called. It will be empty for the generic Importer (we don't need to initialize any thing) but WorkspaceImporter will overload it. protected NodeState resolveUUIDConflict Resolve UUID conflict :p private boolean isAddabble(NodeState parent, NodeInfo nodeInfo) throws ConstraintViolationException, AccessDeniedException, VersionException, LockException, ItemNotFoundException, ItemExistsException, RepositoryException This method is not needed. private boolean isCorrect(NodeState parent, NodeInfo nodeInfo, List propInfos) Not needed. If you are OK with this approach, I will work on this and propose you soon a patch implementing this refactoring. BR, Nico my blog! http://www.deviant-abstraction.net !! WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Assigned To: Jukka Zitting Attachments: GenericImporter.patch, SysViewImporter.patch, WorkspaceImporter.patch, WorkspaceImporter.patch, WorkspaceImporter.patch Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-580) Should be public: NodeType[] registerNodeTypes(List defs)
[ http://issues.apache.org/jira/browse/JCR-580?page=comments#action_12437614 ] Nicolas Toper commented on JCR-580: --- Hi, Which class are you writing about please? Should be public: NodeType[] registerNodeTypes(List defs) --- Key: JCR-580 URL: http://issues.apache.org/jira/browse/JCR-580 Project: Jackrabbit Issue Type: Improvement Components: nodetype Affects Versions: 1.0.1 Reporter: Dan Connelly Allow XSD schema file to be the direct souce of custom NodeTypes for a Level 2 application. Alternatively, but less desirably, add support for the following method in SchemaConverter class: public InputSource getNodeTypeInputSource(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-569) WorkspaceImporter Refactoring
[ http://issues.apache.org/jira/browse/JCR-569?page=all ] Nicolas Toper updated JCR-569: -- Attachment: WorkspaceImporter.patch Hi, As told, it was untested. Now it is and working (according to the unit test). BR Nicolas WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Attachments: GenericImporter.patch, SysViewImporter.patch, WorkspaceImporter.patch, WorkspaceImporter.patch Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-569) WorkspaceImporter Refactoring
[ http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12435345 ] Nicolas Toper commented on JCR-569: --- Just to be sure everything is all right: I have checked with my machine. Only 2 tests are run when calling o.a.j.test.core.xml. Are they the only ones run? Is the JCR test suite what is in /jackrabbit/src/test? Nico WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Attachments: GenericImporter.patch, SysViewImporter.patch, WorkspaceImporter.patch, WorkspaceImporter.patch Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-569) WorkspaceImporter Refactoring
[ http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434496 ] Nicolas Toper commented on JCR-569: --- Sure. Here it is: Introduction The current o.a.j.core.xml.WorspaceImporter class has one main responsability: to import data provided by a ContentHandler to the repository. It needs to check imported data to maintain consistancy and coherence of the repository and in some cases rejects them. The calling stack is: - WorkspaceImporter implements Importer - SysViewImportHandler - SaxParser (and various classes associated) - Other classes The Importer interface is composed of 4 methods: start, end, startNode, endNode. The current WorkspaceImporter contains only two protected classe Currently the code is complex to grasp and have some issues I would like to solve with this iteration of the backup tool (I am using this class heavily). Issues I am trying to solve: - Methods are too long: there are 7 methods in this class for 619 lines. In average one method per 88 lines. This goes with the 4 levels of if/else. This code is hard to debug. - Complexity: there is no clear separation of concerns between methods. This is partly due to the Importer interface quite close to the XML. For instance, startNode() checks the validity of the import ad endNode do. We need to create more methods giving a role to each one. - Factorizing/Code duplicate: Right now we check several times the same thing and sometimes not at all. For instance we check the sanity of the workspace at the end of each node and at the end of the import. We also check several times if a node can be added without disrupting the consistancy of the repository. We should have a private dedicated method for that. - Bugs: jcr:root is not handled correctly and other bugs have been detected. Since the code is hardly readable, - Lack of flexibility: I will give just an example. Because of this monolothic design (only 7 methods), the checks are embedded in each method (cf. upper). I had to subclass the 4 methods of the Importer interface. Also the WorkspaceImporter initiates versioning if needed and remap some UUID all the time. Solution My proposal is in four parts: - Add some private methods to abstract some of the complex issue this class is managing - Add more control in the constructor (for instance for our backup tool): add a constructor with the BatchedItemOperation so we can choose if needed the needed ItemStateManager. (For instance to restore the version history). - Add a raw flag in the constructor to import the content as it is without initializing versioning and escaping some checks. This is a use case already encountered - With this new design, solve remaining bugs and handle the jcr:root issue. This new class will be subclassed by WorkspaceImporter to handle the workspace (I am not using it for now) and for the sanityCheck(): therefore it will be only a few lines and we will have good SoC. Please have a look as the patch proposed earlier to have a look at the design and the new code (it is far from over and a lot of methods are incomplete). BR Nicolas WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Attachments: SysViewImporter.patch Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-569) WorkspaceImporter Refactoring
[ http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434497 ] Nicolas Toper commented on JCR-569: --- Hi Stefan, About your first point, you are right: this is why I sent yesterday a more in depth analysis. This JIRA issue will be used as Jukka suggested it, for refactoring issue of this class only. I would like to create two classes: one generic Importer (name to be defined) and one dedicated to import a workspace. I would use the generic Importer for the backup and others could use it when they need to batch load some data (of course, it is more complex to use and set up). The WorkspaceImporter would be used for the same use case as now. The WorkspaceImporter constructor would stay the same to avoid backward compatibility issue. Here is a quick descriptive of each methods of the generic Importer. They are private since no other class need them (this class is used with the ContentHandler). private boolean checkNode(NodeInfo nodeInfo) Check if the node can be imported to the repository. For instance, it can try to delete a protected node, the same node might already exist (it can depend on the ImportUUIDBehavior used) or the node can be incorrect according to the node type in the repository. Some checks are escaped if raw mode is chosen. If the node is not correct, it puts the skip mode on true to exclude this subtree. When the subtree is over, the skip mode is put to off. If the error is serious (constraint issue for instance), an exception will be thrown. private NodeState createNode(NodeState parent, NodeInfo nodeInfo) Create the NodeState depending according to ImportUUIDBehavior flag private void createProperties(NodeState myNode, List propInfos) Create the properties depending according to ImportUUIDBehavior flag private boolean isSkipped(NodeInfo nodeInfo) if we are in skip mode return true; else false. private void postProcess(NodeState node) Initialize if raw == false, this method is not called. It will be empty for the generic Importer (we don't need to initialize any thing) but WorkspaceImporter will overload it. protected NodeState resolveUUIDConflict Resolve UUID conflict :p private boolean isAddabble(NodeState parent, NodeInfo nodeInfo) throws ConstraintViolationException, AccessDeniedException, VersionException, LockException, ItemNotFoundException, ItemExistsException, RepositoryException This method is not needed. private boolean isCorrect(NodeState parent, NodeInfo nodeInfo, List propInfos) Not needed. If you are OK with this approach, I will work on this and propose you soon a patch implementing this refactoring. BR, Nico my blog! http://www.deviant-abstraction.net !! WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Attachments: SysViewImporter.patch Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-569) WorkspaceImporter Refactoring
WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-569) WorkspaceImporter Refactoring
[ http://issues.apache.org/jira/browse/JCR-569?page=all ] Nicolas Toper updated JCR-569: -- Attachment: SysViewImporter.patch This is the skeleton. This class is not to be included in JR code. WorkspaceImporter should inherit this class so no BatchedItemOperations is directly passed to it. Please give me your feedback. Nicolas WorkspaceImporter Refactoring - Key: JCR-569 URL: http://issues.apache.org/jira/browse/JCR-569 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Attachments: SysViewImporter.patch Hi, As you know, I have run into an issue with the backup tool using the WorkspaceImporter. I ended up copy/pasting large body of code since the current WorkspaceImporter was not flexible enough for my use (in my class called SysViewImporter). This solution was perfectly valid for Google SoC (a lot of time constraints) but unacceptable in the long run for any project (we hate large body of duplicate code :p). Also, some issues have been raised with this class (i.e. jcr:root importation, allowsSameNameSiblings issue). Overall I feel this class is circumvoluted and really hard to understand. For instance, the current code contains at most 5 imbricated if and uses a lot of different ways to pass information (stacks, objects set on null). I tried to refactor my SysViewImporter and the WorkspaceImporter but it implies a new code for the WorkspaceImporter and the SysViewImporter. Here is its skeleton! I first wanted to gather the community feedback before stepping in. I tried moving all work code away from the startNode method and reorganise it for readilibility. Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: BIO.patch Add a flag autoCreate to know whether or not to create autocreate Node. As suggested by Jukka, it avoids to create a specific class to restore the NodeVersionHistories. Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: PropInfo.patch Set a flag in PropInfo in the apply method to escape or not the protected properties. This flag is by default set to the usual behavior (as with BatchedItemOperations), you need to explicitaly call setSkipProtected to change it. It avoids to createe a new class while restoring. Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: patch-backup-040906.txt Hi, Here are some refactoring to the backup tool. This goes in the contrib package for the backup tool. It is mainly clean up of the code (remove some unused variables and comments) There is one issue remaining with CRC check in the zip. Maybe you can help me: I calculate a CRC for each entry. With the debugger, I see it there, but when I open the file in read mode, it is not here anymore. Does anyone know why? It is important I believe. Next steps are for me to code two patches: 1- To integrate Jukka's ideas 2- To implement those changes in this code (only a few lines will be changed) BR Nico Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-556) Refactoring of the BackupTool
Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt This is a new class I propose to put in o.a.j.state. It is designed to update easily the Node Version Histories. It is used by VersionManagerImpl.importVersions(...). The regular LocalItemStateManager was performing some checks on the protected nodes. Depending on its other uses, we might consider refactoring it with LocalItemStateManager since they share a lot. Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: patch-jr-010906-PropInfo.txt This patch contains a few updates I had to PropInfo. I added three getters and switched to other getXXX to public. Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: patch-jr-010906-SysViewImporter.txt SysViewImporter: takes a system view XML document and import it as it is in an empty repository. It is heavily based on the WorkspaceImporter but doesn't extend it (I would have to put too many methods in protected for this; tell me if you would be ok with this change though). Here are the differences: 1/ it escapes the isProtected check and doesn't autoCreate nodes. It checks if there are some contents in the destination, if yes it throws an exception. 2/ You have more control through the constructor than the WorkspaceImporter since you specify which BatchedItemOperations you want to use. 3/ There are no conflicts/replace so basically, it just creates nodes and so is a lot simpler thant the WorkspaceImporter. Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: patch-jr-010906-VersionManagerImpl.txt This patch adds importVersions in the VersionManagerImpl. Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ http://issues.apache.org/jira/browse/JCR-556?page=all ] Nicolas Toper updated JCR-556: -- Attachment: patch-jr-010906-RepositoryImpl.txt This is a small update to RepositoryImpl. I wanted to avoid updating the interface VersionManager to add the method importVersions(...). This slight change allows me to since we can fetch VersionManagerImpl directly from the Repository (and we know it is always a VersionManagerImpl) Refactoring of the BackupTool - Key: JCR-556 URL: http://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-jr-final1.tar.gz This is the proposed path to the core for the backup tool. Sorry for the 4 patches but some Gremlins have invaded my computer and created a lot of problem with SVN. Here are the modifications I propose: - Update to PropInfo. Please see relevant thread on ML. - Update to VersionManagerImpl and to RepositoryImpl. In order to restore the NodeVersionHistories, I need to gain access to the VersionManagerImpl persistence (through a getter) manager. For this, I need to put the getVersionManager() of RepositoryImpl in public (I couldn't use the one from SessionImpl since there can be a XAVersionManager and the cast to VersionManagerImpl doesn't work in this case) - Add a NodeVersionHistoriesUpdatableStateManager It is a specific UpdatableStateManager designed specifically to update the NodeVersionHistories. It is heavily based on the LocalItemStateManager. I have to be able to connect the imported NodeState so I had to put this class in the o.a.j.core.state package and couldn't put it in the backup one. (connect is protected to state and it is *really* a bad idea to put in public). The idea was to be able to work with a BatchedItemOperation class so to keep as much as possible its original semantic. I am sure there is a better way to handle those needs instead of updating the core but I didn't find any yet. As soon, as we all agree, I will update the relevant part of my code (in backup and in this patch) and document them properly. Cheers, Nico PS I am cleaning up my SVN so next time, I can post one patch for all. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: backupTool-final1.tar.gz, jackrabbit-1.patch.txt, patch, patch-060808-backup.txt, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-backup-060728.txt, patch-backup-060803.txt, patch-backup-090806.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch-jackrabbit-060728.txt, patch-jr-060803.txt, patch-jr-final1.tar.gz, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-535) Ignore root node when importing through sysView
Ignore root node when importing through sysView --- Key: JCR-535 URL: http://issues.apache.org/jira/browse/JCR-535 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Minor Attachments: patch-1-Ignore-root-node.txt When importing through a sysView, we should ignore the root node. It is in the sysView to provide a root XML node, but the importer is going to attach it to the repositorys root node... Which would create another root node and often raise exception. This is a know issue I needed this behavior to change for the backup tool, since I use the sysView. Therefore, I havce slightly updated the WorkspaceImporter. Maybe I should update too the SessionImporter so we have a consistant behavior. What do you think? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-backup-090806.txt Hopefully, this is one of the last patches for this project :) Everything is working but the importXML method in the VersionManager hasn't been finished yet (so not committed to core) so the node version history restore is not working (and actually raises an exception since it looks for it). If you need the tool already, please deactivate the node version history restore for now. The code still needs clean up and documentation but the meat of this contrib project is here. ETA: Monday. Next steps: finish the importXML method (currently), clean up (trailing spaces mostly), document (readme, wiki page), test + bug patches and requirements for a version 2. Some ideas have already been put for a V2 on the wiki page. I plan to start working on it after Google SoC and when we would have gathered enough users feedback. Please feel free to already put your ideas for a v2 and of course, soon, please test the backup/restore. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-060808-backup.txt, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-backup-060728.txt, patch-backup-060803.txt, patch-backup-090806.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch-jackrabbit-060728.txt, patch-jr-060803.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-060808-backup.txt - A few classes has been cleaned up and are ready for production (Until BackupManager not included) - There is still the NodeVersionHistories.restore() unfinished. Eventually, I will unprotect the NodeDef and protect them before going out of the methods (the easier for me I feel). - I have a bug in WorkspaceBackup.restore() but I can't seem to find it: no content is restored, no error is given. Can you help me on this? Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-060808-backup.txt, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-backup-060728.txt, patch-backup-060803.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch-jackrabbit-060728.txt, patch-jr-060803.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-jr-060803.txt Jackrabbit patch to core to allow restore. 2 updates: - Added to NamespaceRegistryImpl this method public boolean isRegistered(String prefix). I need to avoid launching of an exception. - Added to RepositoryImpl, public void setRepProps(Properties props) and public void setRootNodeId(NodeId ni) to restore correctly the repository. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-backup-060728.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch-jackrabbit-060728.txt, patch-jr-060803.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-521) Add a method public boolean hasNodeType(String name) in NodeTypeManagerImpl
Add a method public boolean hasNodeType(String name) in NodeTypeManagerImpl --- Key: JCR-521 URL: http://issues.apache.org/jira/browse/JCR-521 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Trivial As seen in the ML, we plan to add this method and update this class and the interface JackrabbitNodeTypeManager -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-521) Add a method public boolean hasNodeType(String name) in NodeTypeManagerImpl
[ http://issues.apache.org/jira/browse/JCR-521?page=all ] Nicolas Toper updated JCR-521: -- Attachment: patch060728.txt Here is the patch implementing those changes. Add a method public boolean hasNodeType(String name) in NodeTypeManagerImpl --- Key: JCR-521 URL: http://issues.apache.org/jira/browse/JCR-521 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Nicolas Toper Priority: Trivial Attachments: patch060728.txt As seen in the ML, we plan to add this method and update this class and the interface JackrabbitNodeTypeManager -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-521) Add a method public boolean hasNodeType(String name) in NodeTypeManagerImpl
[ http://issues.apache.org/jira/browse/JCR-521?page=all ] Nicolas Toper updated JCR-521: -- Attachment: patch-060728-3.txt Correcting A and B Add a method public boolean hasNodeType(String name) in NodeTypeManagerImpl --- Key: JCR-521 URL: http://issues.apache.org/jira/browse/JCR-521 Project: Jackrabbit Issue Type: New Feature Components: nodetype Reporter: Nicolas Toper Assigned To: Jukka Zitting Priority: Trivial Fix For: 1.1 Attachments: patch-060728-3.txt, patch060728-2.txt, patch060728.txt As seen in the ML, we plan to add this method and update this class and the interface JackrabbitNodeTypeManager -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=comments#action_12423945 ] Nicolas Toper commented on JCR-442: --- Hi, The first part of the project is completed!!! Backup is working just fine :) I am posting all patches ASAP. I am waiting for your great comments. Next steps: the restore operation + extensive testing + some clean up (see TODO tagged items in the code) Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-backup-060728.txt Working backup operation + relevant test case. No new classes added. A lot of issues remain: mostly documentation and code cleaning. They are tagged as TODO in the source code. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-backup-060728.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-backup-060726.txt Patch including (nearly) all corrections asked by Jukka. See comments please. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-jackrabbit-060726.txt New patch. Implements corrections asked by Jukka. I changed a lot less methods Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=comments#action_12423670 ] Nicolas Toper commented on JCR-442: --- Hi Jukka, Here are my answers :p a/ Done. Maybe I should put in the constructor of Backup the session since it's shared by a few classes. What do you think? I had to look for the default workspace to get a System Session. Can we assume it's always there? b/ It's actually already the case. I just needed to cast Workspace to WorkspaceImpl. I corrected the code on my side. c/ Maybe we should add an external tool session instead of sharing a session with JR internals. What do you think? d/ This is what I did first, but I use it in BackupConfigurationParser and it is already used in RepositoryConfigurationParser. It is why it's there. (for now I don't use the PM but this might change). I suggest to leave a TODO on this point and see if it's still needed there at the end of the project. Do you agree? e/ At first I put it in my backup class and then I thought it could be useful to others. It's why it's there. As you can see, I can put it in my backup class if needed but this functionnality can be needed also by other application. What do you think? f/ Done. g/ The test case is renamed with the right header. h/ I have checked the tabs issue *also* in my Jackrabbit patch :p Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-backup-060725.txt first sizable patch. Not everything is working yet... - solved tab issue - renamed ManagerBackup as BackupManager - no more SizeException - added missing ASF license headers - test case added in src/test: some path are hardcoded: how should I generify the test case? Which other ones would you want? - Backup nearly over. (I am starting to work on the restore as soon as we all agree on the backup.) A lot of todo are still there :p - I have seen a lot of sanityCheck in the current code. Should I put also a lot of them in mine :p? A list of question is coming by email :) Thanks for your help Nico Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-backup-060719.txt Patch for the backup tool: 1/ Parsing of the configuration file is over 2/ Instanciation of the backup manager 3/ First draft of the ZipBackupIOHandler. The code is still a work in progress. All your comments are greatly appreciated. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-jackrabbit-060718.txt a) Make RepositoryConfigurationParser a subclass of ConfigurationParser and use inheritance to access the protected methods from ConfigurationParser. b) Remove the createSubParser() method from the ConfigurationParser base class, it's only needed by RepositoryConfigurationParser. c) Same issue as always for those patches: I delete and recreate the class. I don't know if it's solved but we won't have anymore this problem anyway for the next patches. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-backup-060716.txt - XML configuration file is correctly parsed and interpreted by the Backup tool. - code compiles and is tested - Indentations is composed of spaces and not anymore tabs. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch-jackrabbit-060716.txt - The new correct patch (I don't try to delete and recreate the same file within the same patch) - No tabs :p Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-jackrabbit-060716.txt, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: jackrabbit-1.patch.txt Jackrabbit patch with 2 classes for ConfigurationParser. I couldn't test the class since Jackrabbit does not currently compile through Maven. In theory no problem, since I just moved some methods from one class to the other (and add super where needed). Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Issue Type: New Feature Reporter: Jukka Zitting Attachments: jackrabbit-1.patch.txt, patch, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch.txt LaunchBackup tested and completed. (issue with Eclipse and SVN so please tell me if you have a problem importing the patch) Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Type: New Feature Reporter: Jukka Zitting Attachments: patch, patch.txt, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch.txt Deleting the backup package and restoring RepositoryImpl to its previous configuration. Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Type: New Feature Reporter: Jukka Zitting Attachments: patch, patch.txt, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-442) Implement a backup tool
[ http://issues.apache.org/jira/browse/JCR-442?page=all ] Nicolas Toper updated JCR-442: -- Attachment: patch.txt ConfigBackup is now called BackupConfig. It is my first accepted patch on Apache Jackrabbit :) Implement a backup tool --- Key: JCR-442 URL: http://issues.apache.org/jira/browse/JCR-442 Project: Jackrabbit Type: New Feature Reporter: Jukka Zitting Attachments: patch, patch.txt, patch.txt Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper. The original project requirements are: Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
