You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Nicolas <nt...@gmail.com> on 2006/08/14 21:34:45 UTC
Adding a method to PropInfos
Hi,
In order to restore properly the content of a workspace, I needed to escape
some checks the regular WorkspaceImporter class was doing. I rewrote a
custom Importer with no problem. ( It's basically a copy/paste of the
current importer without the check: it's a short term solution for now but a
working one. We plan to implement a switch to escape all checks in JR
internal.)
However, I couldn't do the same with the PropInfo class. Therefore I add to
add a restoreApply method, which is the same as apply but without the check.
Maybe I should rename it? I choose restoreApply to emphathise the fact that
it's reserved for the restore operation.
What do you think?
BR
Nico
my blog! http://www.deviant-abstraction.net !!
Re: Adding a method to PropInfos
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/16/06, Nicolas <nt...@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 <st...@gmail.com> wrote:
> >
> > On 8/16/06, Nicolas <nt...@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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
I agree completely with you Toby. Actually it is what I did initially. But:
- we tried to minimize impact on core for the backup tool. The updates I
propose are the one to minimize its impacts. If we add a import/export, why
not add them on all backuped/restored resources? I would be in favor of
either adding this method for all resources or to none. For instance to make
a resource backuppable, we could implement a Backupable Interface instead of
relying on a <Resource>Backup class with two main methods.
- If I add a method i the VersionManager, I would have to put some code to
escape data consistency checks which is something Stefan wanted to avoid.
The underlying issue I think is what should be the place of the backup tool:
should be add specific method to backup/restore in core (as thought
initially) or should we minimize core modifications?
Both ways have advantage and drawbacks. I would go however for a tighter
coupling especially since hotbackup will be easier to implement this way.
I have checked mysqldump code and they simply make SQL request on each
table. So they didn't add any specific code (but at the same time, they are
simply dumping mysql tables...).
Right now, the code try to be as much separated as possible, but I can quite
easily refactor the other way.
What are your thoughts on this issue?
Nicolas
On 8/17/06, Tobias Bocanegra <to...@day.com> wrote:
>
> > The patches are posted.
> >
> > I am waiting for your feedback to perform the last refactoring so we can
> > start using it.
> >
>
> From Jira Issue:
> > - Update to VersionManagerImpl and to RepositoryImpl.
> > In order to restore the NodeVersionHistories, I need to gain access to
> the
> > VersionManagerImpl persistence (through a getter) manager. For this, I
> need
> > to put the getVersionManager() of RepositoryImpl in public (I couldn't
> use
> > the one from SessionImpl since there can be a XAVersionManager and the
> > cast to VersionManagerImpl doesn't work in this case)
>
> this is a wrong asumption, that the version manager stores the
> versions in a persistence manager. the version manager is
> intentionally kept abstract, so that an implementation could use
> another, more efficient way to store the versions. it's not good to
> access the vesions persistence manager directly.
>
> i would prefer adding 3 methods to the version manager:
>
> public void exportVersions(OutputStream out)
> public void exportVersions(ContentHandler handler)
> public void importVersions(InputStream in, boolean update)
>
> that does a systemview like export/import of all version histories,
> directly below the export-root.
>
> doing so, the version export/import is not tied to the persistence
> anymore.
> regards, toby
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> 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 >---
>
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
Re: Adding a method to PropInfos
Posted by Tobias Bocanegra <to...@day.com>.
> The patches are posted.
>
> I am waiting for your feedback to perform the last refactoring so we can
> start using it.
>
>From Jira Issue:
> - Update to VersionManagerImpl and to RepositoryImpl.
> In order to restore the NodeVersionHistories, I need to gain access to the
> VersionManagerImpl persistence (through a getter) manager. For this, I need
> to put the getVersionManager() of RepositoryImpl in public (I couldn't use
> the one from SessionImpl since there can be a XAVersionManager and the
> cast to VersionManagerImpl doesn't work in this case)
this is a wrong asumption, that the version manager stores the
versions in a persistence manager. the version manager is
intentionally kept abstract, so that an implementation could use
another, more efficient way to store the versions. it's not good to
access the vesions persistence manager directly.
i would prefer adding 3 methods to the version manager:
public void exportVersions(OutputStream out)
public void exportVersions(ContentHandler handler)
public void importVersions(InputStream in, boolean update)
that does a systemview like export/import of all version histories,
directly below the export-root.
doing so, the version export/import is not tied to the persistence anymore.
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
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: Adding a method to PropInfos
Posted by Tobias Bocanegra <to...@day.com>.
whatever you do. don't use the persistence manager of the versions.
that is definitely the wrong way.
On 8/17/06, Nicolas <nt...@gmail.com> wrote:
> Hi Dominique,
>
> I agree on this. But I don't see any other alternative than the one Toby
> described: add an import/export method to the VersionManager and this means
> integrating the backup tool to the core which is something we didn't want to
> do at first.
>
> You raise an interesting question about the storage format reliability (in
> the "aging" sense). It is one of the main reason why I used the sysView for
> workspace and versioning backup. It is a reliable format since it is
> specified in JCR. The specification also specifies the
> /jcr:system/jcr:versionStorage tree so we will always have a sysView of
> those resources. It allowed us to piggyback on a working, reliable and
> implemented format. I propose to stick with this format for now and
> rediscuss this point when we will be thinking of the version 2 of this tool
> (quite soon).
>
> Cheers
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
> On 8/17/06, Dominique Pfister <do...@day.com> wrote:
> >
> > Hi Nicolas,
> >
> > as Tobi pointed out, I would not rely on the fact that the
> > VersionManager currently uses a PersistenceManager. This could very
> > easily change in the future. Since sysview importing puts restrictions
> > on the items being imported, I'd rather take a low level approach à la
> > o.a.j.c.BatchedItemOperations and use some custom format when
> > importing/exporting items.
> >
> > Cheers
> > Dominique
> >
> >
> >
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
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: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
Hi Dominique,
I agree on this. But I don't see any other alternative than the one Toby
described: add an import/export method to the VersionManager and this means
integrating the backup tool to the core which is something we didn't want to
do at first.
You raise an interesting question about the storage format reliability (in
the "aging" sense). It is one of the main reason why I used the sysView for
workspace and versioning backup. It is a reliable format since it is
specified in JCR. The specification also specifies the
/jcr:system/jcr:versionStorage tree so we will always have a sysView of
those resources. It allowed us to piggyback on a working, reliable and
implemented format. I propose to stick with this format for now and
rediscuss this point when we will be thinking of the version 2 of this tool
(quite soon).
Cheers
Nico
my blog! http://www.deviant-abstraction.net !!
On 8/17/06, Dominique Pfister <do...@day.com> wrote:
>
> Hi Nicolas,
>
> as Tobi pointed out, I would not rely on the fact that the
> VersionManager currently uses a PersistenceManager. This could very
> easily change in the future. Since sysview importing puts restrictions
> on the items being imported, I'd rather take a low level approach à la
> o.a.j.c.BatchedItemOperations and use some custom format when
> importing/exporting items.
>
> Cheers
> Dominique
>
>
>
Re: Adding a method to PropInfos
Posted by Dominique Pfister <do...@day.com>.
Hi Nicolas,
as Tobi pointed out, I would not rely on the fact that the
VersionManager currently uses a PersistenceManager. This could very
easily change in the future. Since sysview importing puts restrictions
on the items being imported, I'd rather take a low level approach à la
o.a.j.c.BatchedItemOperations and use some custom format when
importing/exporting items.
Cheers
Dominique
On 8/17/06, Nicolas <nt...@gmail.com> wrote:
> Hi,
>
> The patches are posted.
>
> I am waiting for your feedback to perform the last refactoring so we can
> start using it.
>
> Cheers
> Nico
>
>
Re: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
Hi,
The patches are posted.
I am waiting for your feedback to perform the last refactoring so we can
start using it.
Cheers
Nico
Re: Adding a method to PropInfos
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/16/06, Nicolas <nt...@gmail.com> wrote:
> Are you OK with those two updates to the core?
Can you send the patches you're proposing?
> 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.
I think Stefan's point about the system view overhead is related to 1)
the inherent overhead in the XML encoding, 2) the base64-encoding of
binaries, and 3) the hierarchical view of the content. 1 and 2 are
pretty well handled by zip compression, but 3 requires the backup tool
to walk the tree hierarchy (in comparison to just linearly dumping all
the node states) when doing the backup.
Using the system view has its benefits and drawbacks, and although I
wouldn't originally have used it for the backup tool, I think Nicolas
has a good case for going with the system view, at least for a first
version of the backup tool. The hard part in that decision is figuring
out the way to do the restore...
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
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 <st...@gmail.com> wrote:
>
> On 8/16/06, Nicolas <nt...@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
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Adding a method to PropInfos
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/16/06, Nicolas <nt...@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 <ju...@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
> > > >
> > >
> > >
> >
>
>
Re: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
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 < 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 <ju...@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
> > >
> >
> >
>
Re: Adding a method to PropInfos
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/15/06, Nicolas <nt...@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 <ju...@gmail.com> wrote:
> >
> > Hi,
> >
> > On 8/15/06, Nicolas <nt...@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
> >
>
>
Re: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
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.
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 <ju...@gmail.com> wrote:
>
> Hi,
>
> On 8/15/06, Nicolas <nt...@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
>
Re: Adding a method to PropInfos
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/15/06, Nicolas <nt...@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
Re: Adding a method to PropInfos
Posted by Nicolas <nt...@gmail.com>.
Hi
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).
What is your other idea about this please?
BR
Nicolas
my blog! http://www.deviant-abstraction.net !!
On 8/15/06, Stefan Guggisberg <st...@gmail.com> wrote:
>
> On 8/14/06, Nicolas <nt...@gmail.com> wrote:
> > Hi,
> >
> > In order to restore properly the content of a workspace, I needed to
> escape
> > some checks the regular WorkspaceImporter class was doing. I rewrote a
> > custom Importer with no problem. ( It's basically a copy/paste of the
> > current importer without the check: it's a short term solution for now
> but a
> > working one. We plan to implement a switch to escape all checks in JR
> > internal.)
> >
> > However, I couldn't do the same with the PropInfo class. Therefore I add
> to
> > add a restoreApply method, which is the same as apply but without the
> check.
> > Maybe I should rename it? I choose restoreApply to emphathise the fact
> that
> > it's reserved for the restore operation.
>
> without knowing exactly what you're up to, i doubt that this would be a
> good
> approach. it rather looks like a nasty hack...
>
> cheers
> stefan
>
>
>
Re: Adding a method to PropInfos
Posted by Stefan Guggisberg <st...@gmail.com>.
On 8/14/06, Nicolas <nt...@gmail.com> wrote:
> Hi,
>
> In order to restore properly the content of a workspace, I needed to escape
> some checks the regular WorkspaceImporter class was doing. I rewrote a
> custom Importer with no problem. ( It's basically a copy/paste of the
> current importer without the check: it's a short term solution for now but a
> working one. We plan to implement a switch to escape all checks in JR
> internal.)
>
> However, I couldn't do the same with the PropInfo class. Therefore I add to
> add a restoreApply method, which is the same as apply but without the check.
> Maybe I should rename it? I choose restoreApply to emphathise the fact that
> it's reserved for the restore operation.
without knowing exactly what you're up to, i doubt that this would be a good
approach. it rather looks like a nasty hack...
cheers
stefan
>
> What do you think?
>
> BR
> Nico
> my blog! http://www.deviant-abstraction.net !!
>
>