jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Toper" <nto...@gmail.com>
Subject Re: Client/Server question
Date Wed, 31 May 2006 11:32:28 GMT

Jukka and I have given a few thoughs on the architecture of the backup tool.
Here is what we recommend for now:

"I think the best way to start would be to add local backup and restore
methods in the standard org.apache.jackrabbit.api.JackrabbitRepository
interface that we have. They could be something like this:

      * Backs up the entire repository contents to the given file.
      * @param filename the name of the backup file to be written
      * @throws IOException if the file cannot be written
      * @throws RepositoryException if the backup fails for another reason
     void backup(String filename) throws IOException, RepositoryException;

      * Restores the entire repository contents from the given file.
      * Note that this will override any existing repository contents.
     * @param filename the name of the the backup file to be read
      * @throws IOException if the file cannot be read
      * @throws RepositoryException if the restore fails for another reason
     void restore(String filename) throws IOException, RepositoryException;

 An easier alternative for the restore method could be a separate
 application that just takes a backup file and recreates the entire
 repository from it. This would nicely avoid all concurrency issues
 during restore."

This strategy is quite simple to implement and the tool is useful to a
 Later on, we would extend it by adding remoting options and new
We would still have a working tool faster. For example extending
the JCR-RMI layer to cover these methods would be relatively simple.

What do you think?

my blog! http://www.deviant-abstraction.net !!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message