[Jackrabbit Wiki] Update of "BackupTool" by JukkaZitting

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The following page has been changed by JukkaZitting:
http://wiki.apache.org/jackrabbit/BackupTool

------------------------------------------------------------------------------
  
  We want to ease the installation of the backup tool and keep the most flexibility when performing a backup. 
  
- Besides we need to support Jackrabbit installation in its three models: as a shared J2EE resource, as a repository server and as a webapp bundle. Since in this last case we cannot assume any communication layer, we have only one option on where to put the backup tool: as a local backup and maybe a local restore method in the standard org.apache.jackrabbit.api.JackrabbitRepository interface. Jukka? What class should implement this interface? RepositoryImpl in core package?
+ Besides we need to support Jackrabbit installation in its three models: as a shared J2EE resource, as a repository server and as a webapp bundle. Since in this last case we cannot assume any communication layer, we have only one option on where to put the backup tool: as a local backup and maybe a local restore method in the standard org.apache.jackrabbit.api.JackrabbitRepository interface. Jukka? What class should implement this interface? RepositoryImpl in core package? (o.a.j.core.RepositoryImpl -Jukka)
  
- The backup operation is quite flexible. It can be fired from everywhere (application, sysadmin, remote client,…). 
+ The backup operation is quite flexible. It can be fired from everywhere (application, sysadmin, remote client, ...). 
  
  The restore operation would be fired from a separate application which would be the only one using the repository. There are a lot of constraint to restore but since it is a quite rare operation, its impact is quite limited. 
  
- 
- JackRabbit is still a new project. The functionality set would probably evolve. The backup tool need to show good evolution capability so it can follow Jackrabbit evolutions. Jukka and I propose to use a XML configuration file loaded with each save operation. The configuration file would define what resource is to be saved (and therefore restored) and how (by pointing to a class). This way, it is easy to add new kind of resource (and share the code with the community) and create your own backup plan. If the API change a little bit, we would have only to update one class. (The configuration file is backuped with the repository so the restore operation know what to restore).
+ Jackrabbit is still a new project. The functionality set would probably evolve. The backup tool need to show good evolution capability so it can follow Jackrabbit evolutions. Jukka and I propose to use a XML configuration file loaded with each save operation. The configuration file would define what resource is to be saved (and therefore restored) and how (by pointing to a class). This way, it is easy to add new kind of resource (and share the code with the community) and create your own backup plan. If the API change a little bit, we would have only to update one class. (The configuration file is backuped with the repository so the restore operation know what to restore).
  
  For instance, the configuration file would look like this: (it is not a proposition yet, just an example, I will propose later a real format).
  
- 
+ {{{
  <rabbitHole>
- 
- <user>
+   <user>
- 
- <param name=”login” value=”***”>
+     <param name=”login” value=”***”>
- 
- <param name=”password” value=”***”>
+     <param name=”password” value=”***”>
- 
- 
- </user>
+   </user>
- 
- <repository>
+   <repository>
- 
- <resource name=”custom node type” savingClass=”FQN backup class”/>
+     <resource name=”custom node type” savingClass=”FQN backup class”/>
- 
- </repository>
+   </repository>
- 
- <workspaces type=”selected|all” >
+   <workspaces type=”selected|all”>
- 
- <workspace name=”wsp1” />
+     <workspace name=”wsp1” />
- 
- 
- <workspace name=”wsp2” />
+     <workspace name=”wsp2” />
- 
- <workspace name=”wsp3” />
+     <workspace name=”wsp3” />
- 
- 
- </workspaces>
+   </workspaces>
- 
- 
- </rabbitHole >
+ </rabbitHole>
- 
+ }}}
  
  As you can see, we can backup either all workspaces or a specific one and the same class is used to save and restore a resource (we would be implementing a specific interface with two methods: backup and restore). The Javadoc is going to specify the dependency from the save/restore class to the “main” one (using @link?).
  
@@ -96, +78 @@

  
  == Locking strategy ==
  
- For the backup operation, locking will be managed on the backup class level. There is no need for now to hold a global lock for now. We will put a JCR deep lock on the root node of the workspace we are currently saving. If a lock is already held, we would raise an exception (but not kill the backup; it would proceed without the specified workspace). 
+ For the backup operation, locking will be managed on the backup class level. There is no need for now to hold a global lock for now. We will put a JCR deep lock on the root node of the workspace we are currently saving. If a lock is already held, we would raise an exception (but not kill the backup; it would proceed without the specified workspace).
  
  About the Jackrabbit conf files, they are not modified by any processes (even workspace.xml?) so there is no issue.