Stefan, Of course repository restore and system view are two different things but they can be built on the same layers. I can if needed subclass completelly the SysViewHandler to call "my" PropInfos class. This is easy to achieve and would create a better separation between the two. What do you think?
I can tell no loopholes are in the core to prevent security/data consistency issue. This is exactly the problem with the restore operation: I need a way to import uncoherent data (the data will be uncoherent for a few minutes only). For a maintenance operation such as a restore, it should be possible and currently it is not. For instance I had to add a method to get the PersistenceManager of the VersionManagerImpl and implement my UpdatableStateItemManager to import the NodeVersionHistories. This class has to be in core or else, I can't reconnect the Node. This "door" should be open only to maintenance application. Are you OK with those two updates to the core? About the format used for restore: there is only small overhead since all files are zipped. Please keep in mind that the backup tool is only a first version and we might change it afterwards. For this first version, my priority was to have a readable and time standing format. From those point of view, the sysView is good. Cheers Nico On 8/16/06, Stefan Guggisberg <[EMAIL PROTECTED]> wrote:
On 8/16/06, Nicolas <[EMAIL PROTECTED]> wrote: > Hi Stefan, > > The import in Jackrabbit works this way: you call a SAX parser passing him a > content handler (the sysView handler). This handler calls the Importer. > > So the calling stack looks like this: > > Importer > SysViewImportHandler > SaxParser (and various classes associated) > Other classes > > The PropInfo class is called by SysViewHandler and then passed to the > Importer. If I subclass it, I will need to subclass also > SysViewImportHandler and rewrite the whole classes to call my copy/paste > instead of the usual ones. Those classes are tightly coupled. > > It seems it will be hard to support in the long run. I know it looks like a > short term hacks but it is not: I find it legitimate to need to apply some > properties to a node and wanting to escape all regular checks. Don't you > think so? no. great care has been taken so far to avoid loopholes in the core in order to prevent security/data consistency issues. we shouldn't compromise on this just to make the restore implementation more convenient. a system view import and a repository restore operation are 2 different things and require special handling. btw: i am note sure that using the system view serialization format is the right choice for repository backup. it has way to much overhead and we shouldn't encourage users to modify the exported data manually before restoring it, especially if you bypass all consistency checks during the restore. cheers stefan > > Cheers, > Nico > my blog! http://www.deviant-abstraction.net !! > On 8/16/06, Stefan Guggisberg < [EMAIL PROTECTED]> wrote: > > > > On 8/15/06, Nicolas < [EMAIL PROTECTED]> wrote: > > > Of course. > > > > > > Actually the backup tool is backupping all workspaces and the version > > node > > > histories using the XML system view. The advantage of this approach are: > > > > > easiness to check the backup is correct, easiness to modify a backup if > > > needed, built as much as possible on JCR and a little bit on Jackrabbit > > API, > > > built on top of existing code so safer in the long run. > > > > > > Other approaches has been thought of but eliminated compared to the ease > > of > > > use of the system view. Please see the wiki on this. > > > > > > The issue lay in restoring content: the importXML methods have never > > been > > > planned to allow restore. They check the content is correct and do not > > break > > > anything. For instance, you can't write to a protected Item through this > > > method. It is of course the right behavior. This is why I wrote a > > custom > > > importer (heavily borrowing code from the WorkspaceImporter) to escape > > all > > > checks. But I couldn't do this with PropInfo: a class used to pass the > > > property of a Node to an Importer... This class contains a method > > apply. > > > This method checks for protection and I need to escape it. It's why I > > added > > > a method which *do not* check any protection. It is a small method which > > > don't break anything and might be useful for others. I am of course open > > to > > > other ideas on this issue :) I realize it is not the best solution, but > > the > > > best I currently have. > > > > i am not in favor of such short-term hacks in the core. since you're > > already > > using your own classes handling the import ( i.e. restore), why don't you > > use > > a subclass of PropInfo and override the apply() method? > > > > cheers > > stefan > > > > > > > > In the longer term, Jukka suggested to create a parameter maintenance > > mode > > > which would escape all test (and other things) to allow easier > > maintenance > > > of the repository. > > > > > > I have a similar issue with restoring the Node Version Histories but > > it's > > > another post ;) > > > > > > Cheers, > > > Nico > > > my blog! http://www.deviant-abstraction.net !! > > > > > > On 8/15/06, Jukka Zitting < [EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > > > > > On 8/15/06, Nicolas < [EMAIL PROTECTED]> wrote: > > > > > I am working on a backup and restore tool for Jackrabbit. It's why I > > > > need to > > > > > escape all checks since I am writing protected node (for this > > reason). > > > > > > > > Could you elaborate on the details, i.e. why you chose the system view > > > > XML format for the backup, why you can't use the standard import > > > > functionality for restoring the backups, what alternatives have you > > > > looked at, what you think is the best solution, and why you need > > > > changes to Jackrabbit core to implement that? That would give people > > > > more background on why you want to modify PropInfo. Just saying that > > > > it's needed for the restore tool and that you need to write a > > > > protected node doesn't explain the reasoning behind this requirement. > > > > :-) > > > > > > > > BR, > > > > > > > > Jukka Zitting > > > > > > > > -- > > > > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > > > > Software craftsmanship, JCR consulting, and Java development > > > > > > > > > > > > > >
