jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "BackupTool" by JukkaZitting
Date Wed, 31 May 2006 20:43:32 GMT
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.
  

Mime
View raw message