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? 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 > > > >
