jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Adding a method to PropInfos
Date Wed, 16 Aug 2006 15:23:18 GMT
On 8/16/06, Nicolas <ntoper@gmail.com> wrote:
> 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?

i can't tell without having a look at the actual code. however, grabbing the
PersistenceManager from the VersionManager seems to be the wrong
approach. restoring versions and version histories is IMO definitely a task
belonging to the VersionManager's domain, i.e. it should be delegated
to the version manager.

cheers
stefan

>
> 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 <stefan.guggisberg@gmail.com> wrote:
> >
> > On 8/16/06, Nicolas <ntoper@gmail.com> 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 < stefan.guggisberg@gmail.com> wrote:
> > > >
> > > > On 8/15/06, Nicolas < ntoper@gmail.com> 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 < jukka.zitting@gmail.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On 8/15/06, Nicolas < ntoper@gmail.com> 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/ - info@yukatan.fi
> > > > > > Software craftsmanship, JCR consulting, and Java development
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
View raw message