jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: [jira] Commented: (JCR-442) Implement a backup tool
Date Thu, 27 Jul 2006 11:31:11 GMT
Hi,

On 7/27/06, Nicolas <ntoper@gmail.com> wrote:
> c: If you are OK on this, I will create a getExternalSession() class in
> RepositoryImpl. This session will be used for all external application
> (backup, access manager and so on). The external session will have the same
> rights as a SystemSession. It would allow us to isolate two different class
> of use  (external applications with priviledged rights and internal use).
> Are you OK on this?

I was more thinking about adding options for admin username and
password in the backup configuration, and using them through the
normal Repository.login() method. That should get us started with
minimal changes to core while still achieving the required
functionality.

> d and e: agreed. Actually, I tend to move code higher when it is needed in
> two different subclass (so code reuse driving the design :)). Why is it
> wrong please?

Consider the classic case of representing species as OO classes: you
have an abstract base class Animal and two descendants Eagle and Bat.
When you notice that both of them have a fly() method, should you move
that up to the Animal class? No, since fly() is not something all
Animals do. If all the known subclasses share some functionality, it
still doesn't mean that this functionality should necessarily be moved
up in the class hierarchy. It is often a good indication of a need for
refactoring the design, but inheritance is not always the best
solution.

The current ConfigurationParser contains only information about a
fairly generic XML configuration syntax. Making it know about the
persistence manager syntax would change that design. What if we later
on want to use the same configuration mechanism for example for
configuring custom full text extractors used by the search index? In
that case it would make little sense for the base class to know about
persistence managers. Of course the extra method doesn't really harm
anyone, but by the same logic you could just make
BackupConfigurationParser subclass RepositoryConfigurationParser.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message