[Hippo-cms7-user BETA] Question about org.hippoecm.repository.HippoRepository

(Berry) A.W. van Halderen b.vanhalderen at hippo.nl
Mon Jul 21 11:44:12 CEST 2008

On Mon, Jul 21, 2008 at 08:40:20AM +0200, Jettro Coenradie wrote:
> I have a small question. Can someone clarify why the choice was made  
> to create org.hippoecm.repository.HippoRepository and not let it  
> extend the jcr repository interface : javax.jcr.Repository.

Good point, and yes it could have been a javax.jcr.Repository.
Until recently I still was undecided upon whether to let HippoRepository
extend javax.jcr.Repository or not.  Note that HippoRepository has no,
and should not contain any functional code apart from getRepository()
which gives you a full javax.jcr.Repository with no limitations.  The
functions like login() are just convenience, the real login function
is in the Repostory obtained as from getRepository().

> It seems strange to me, especially if you look at the following lines  
> of code:
> HippoRepository repository =  
> HippoRepositoryFactory.getHippoRepository("rmi://localhost:1099/ 
> hipporepository");
> Session session = repository.login(new SimpleCredentials("editor",  
> "editor".toCharArray()));
> Repository standardRepo = session.getRepository();
> String[] keys = standardRepo.getDescriptorKeys();
> for (String key : keys) {
>     System.out.println("repo property key : " + key + ", value : " +  
> standardRepo.getDescriptor(key));
> }

The following would have been clearer:
  HippoRepository repositoryConnector
  repositoryConnector = HippoRepositoryFactory.getHippoRepository(location);
  javax.jcr.Repository repository = repositoryConnector.getRepository();

The HippoRepository is not, or not just, a JCR repository.  It contains
embedded logic (but unnecessary for the developer user to handle) on how
to handle connecting to remote repository and we can put in reconnecting
modules in where if we really need to.

The basic reason for me to keep it as is (apart from clarification through
perhaps renaming HippoRepository to HippoRepositoryConnector and/or
the above code change) lies in the reason for connecting to remote

If a repository is remote, it would be nice if the JCR API is available
through RMI.  This means that the javax.jcr.Repository interface
should be implemented by a remoteable object.  If this class (meaning
HippoRepository if it would implement javax.jcr.Repository) is remotable
then there are all kind of restrictions and all of the methods are
always accessed remotely.

Rather than doing this you should view the HippoRepository class as
a connector class, for accessing a JCR repository.  Itself can return
a connection to a directly RMI exported JCR repository, or a SPI
based repository, or (heavens forbid) WebDav repository.  All this is
then hidden because of the combination HippoRepositoryFactory and
a non-exported HippoRepository class.

Quite technical though, we were not expected to be peer-reviewed
on code level..

> repo property key : jcr.repository.vendor, value : Apache Software  
> Foundation

Maybe we should change this property, but this is a non-technical decision
as well.

Berry A.W. van Halderen       b.vanhalderen at onehippo.com / berry at halderen.net
Disclaimer: the above is the author's personal opinion and is not the opinion
or policy of his employer or of the little green men that have been following
him all day.

More information about the Hippo-cms7-user mailing list