Re: Client/Server question
On 5/31/06, Nicolas Toper <[EMAIL PROTECTED]> wrote: You will have actually a version that operate on streams. I will tell you more in the next few days about the proposed design and functionnalities. yah, i saw that after reading the entire thread :) thanks nico!
Re: Client/Server question
You will have actually a version that operate on streams. I will tell you more in the next few days about the proposed design and functionnalities. a+ Nico my blog! http://www.deviant-abstraction.net !!
Re: Client/Server question
On 5/31/06, Nicolas Toper <[EMAIL PROTECTED]> wrote: /** * 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; i like it. how about adding alternate versions that operate on streams? i have an eventual requirement for cosmo to add online backup and restore functionality (ideally for specific subtrees within a workspace, but an entire workspace or the entire repository will suffice for now), and i need to send the data/receive it over webdav rather than from the local filesystem.
Re: Client/Server question
Actually, Jukka and I decided to add the hotbackup fonctionnality in a next step. I will design the tool so this can be added easily later on. We want to create a tool "battle tested" and we fear adding a proxyPM might spread our effort and add too much testing cases for a first step (with probable appearances of transient and intermittent bugs). Please keep in mind, it is the first time, I am working with JackRabbit. See past Jukka mail: "This is something that we should look at later on. Modifying the internal persistence data path is quite risky in terms of possible new bugs and regressions so I'd rather not extend the scope of the SoC project to cover that. I'd be happy with just a global write lock that guarantees data consistency in the repository. For the SoC project I'd even be OK with a tool that simply relies on the administrator to enforce a no-write policy during backup. It's still better than we have now and we can extend and improve the solution later on." I will probably add hotbackup on one form or another after the Google SoC. BR, Nicolas my blog! http://www.deviant-abstraction.net !! On 5/31/06, David Kennedy < [EMAIL PROTECTED]> wrote: What happened to the idea of backing up to a PesistenceManager and restoing from one as well? As long as you add an interface and the PersistenceManager implements the backup/restore interface, it's still feasible, but was there a problem with this strategy? David "Nicolas Toper" <[EMAIL PROTECTED]> wrote on 05/31/2006 08:51:31 AM: > Hi Felix, > > You are right on both points. I will do as you suggest. > > Thanks for your input. > > Best Regards > Nico > my blog! http://www.deviant-abstraction.net !! > > On 5/31/06, Felix Meschberger < [EMAIL PROTECTED]> wrote: > > > > 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 > > > > > >
Re: Client/Server question
(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. well, maybe you need several files to store the data. or maybe a random access file. so streams might also a bit limiting (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. yep. and they probably also encapsulate the exact storage mechanism. -- -< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 ---< http://www.day.com >---
Re: Client/Server question
What happened to the idea of backing up to a PesistenceManager and restoing from one as well? As long as you add an interface and the PersistenceManager implements the backup/restore interface, it's still feasible, but was there a problem with this strategy? David "Nicolas Toper" <[EMAIL PROTECTED]> wrote on 05/31/2006 08:51:31 AM: > Hi Felix, > > You are right on both points. I will do as you suggest. > > Thanks for your input. > > Best Regards > Nico > my blog! http://www.deviant-abstraction.net !! > > On 5/31/06, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > >
Re: Client/Server question
Hi Felix, You are right on both points. I will do as you suggest. Thanks for your input. Best Regards Nico my blog! http://www.deviant-abstraction.net !! On 5/31/06, Felix Meschberger <[EMAIL PROTECTED]> wrote: 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
Re: Client/Server question
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 !!
Re: Client/Server question
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 !!
