jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <fmesc...@gmail.com>
Subject Re: Client/Server question
Date Wed, 31 May 2006 12:12:32 GMT
Hi Nicolas,

I agree to include these methods on the repository layer. But thinking
about the extent - rather than the intrincacies of handling concurrent
modifications while backing up - I would have some remarks:

(1) I would modify the signature to take InputStream and OutputStream
objects, resp. This provides for more flexibility in terms of source
and destination of the backup data.

(2) Initially you mentioned a configuration file for the
backup/restore procedures. I suggest you define configuration classes
(interfaces), which can load/store themselves to and from streams
(yes, I do not like being locked into File instances :-) and to add
instances of the toplevel configuration (e.g. BackupConfiguration) as
a parameter to the backup/restore methods.

These two changes would greatly improve the flexibility using the API
from within an application as opposed to from the command line. Also
testing would be greatly simplified, I suppose.


On 5/31/06, Nicolas Toper <ntoper@gmail.com> wrote:
> Hello,
> 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
> sysAdmin.
>  Later on, we would extend it by adding remoting options and new
> functionnality.
> 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?
> BR
> Nico
> my blog! http://www.deviant-abstraction.net !!

View raw message