jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: Refactoring of the backupTool
Date Sun, 03 Sep 2006 09:40:02 GMT
Hi

On 9/2/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:

> How about refactoring the original BatchedItemOperations class to a
> base class that doesn't do any of the checks (or has just empty
> placeholder methods for the checks) and a subclass that contains the
> checks. Or even better, refactor the checks to a separate Checker
> class to use composition instead of inheritance for the functinality.
> This way there wouldn't be a need to override and duplicate existing
> functionality in a subclass as you could achieve the goal simply by
> using the base class or a different composition.


I agree with you this would be better but one of the design goal of the
backup
tool was to minimize impact to the existing core.

I think it would make sense in here as well to refactor the
> WorkspaceImporter class instead of duplicating the code in a separate
> class.


It is exactly the same issue: some checks are escaped and more control is
given than with the WspImporter.

What I propose is to finish the backup tool (basically comment the classes
in contrib package) and implement those refactor before the version 2 of the
backup tool: there is nothing urgent, nor imperative to them. The updates
would be transparent for everyone.


This seems a bit overkill for just the version import. Could the
> importer be refactored so that it could work with a smaller interface
> than the full UpdatableStateManager?


No, I tried this before :) Well it is possible, but not easily done. I
couldn't use the BatchedItemOps. Any idea?


I'm a bit concerned about this, the version manager should be private
> to the repository. I'd rather see something like a more focused
> WorkspaceImpl.getVersionHistoryImporter() method that only works when
> you have administrator access.


I don't understand your concern. Basically it is pretty much the same as
session.getVersionManager() (already public) but I am sure I can cast it to
VersionManagerImpl whereas a Session.getVersionManager might be a
VersionManagerImpl or a XAVersionManagerImpl. To me it is just a convenience
method.

The other solution was to add a method to VersionManager interface and one
method to XAVersionManagerImpl and VersionManagerImpl but since we want to
minimize change, my approach was best and since you would access through a
session the versionManager, there was no real concern about putting it
public.

BR
Nico
my blog! http://www.deviant-abstraction.net !!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message