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.
Regards
Felix
On 5/31/06, Nicolas Toper <[EMAIL PROTECTED]> 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 !!
