jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Generic JCR repository factory
Date Tue, 20 Oct 2009 17:47:15 GMT
Hi,

Jukka Zitting schrieb:
> Hi,
> 
> The current jackrabbit-jcr-client component contains a
> RepositoryFactory implementation that can choose between different
> Repository implementations based on given parameters. Currently it
> depends on the SPI implementations encoded in the
> Jcr2spiRepositoryFactory class in jackrabbit-jcr2spi and on the
> RepositoryFactoryImpl class in jackrabbit-core. However, the
> jackrabbit-jcr-client POM only declares those as test dependencies, so
> a client application needs to explicitly add the required
> implementation dependencies.
> 
> Some thoughts on this:
> 
> 1) Is there a reason why this generic RepositoryFactory implementation
> couldn't go to jackrabbit-jcr-commons? We obviously want to keep the
> implementation dependencies optional, so having the class in
> jcr-commons would not affect the dependency set. And since all of our
> repository implementations (core, jcr2spi + spi2dav, etc.) already
> depend on jcr-commons, a client would not need any extra dependencies
> to use this functionality.
> 
> 2) It looks to me like the functionality inside the
> Jcr2spiRepositoryFactory class could/should be merged with the
> jcr-client RepositoryFactoryImpl.
> 
> 3) How about using URIs as a simple configuration mechanism? A file:
> URI pointing to a repository directory would start a normal
> jackrabbit-core repository using a repository.xml from within the
> directory (or a custom one specified in a URI parameter). A http: URI
> would point to a DAV(ex) endpoint or possibly a HTML page with an
> appropriate <link/> tag pointing to the endpoint. People are already
> familiar with URIs, so documenting and communicating such
> configurations would be easy.

This basically sounds great (and probably long overdue ;-) )

Some enhancement proposals:

 * file:// : the file URL may also point to a repository configuration
file, in which case the repository is configured from that file and
started in the directory containing the file.

 * http:// : in addition to plain WebDAV and HTML w/<link> we might also
support a davmount URL ([1])

> 
> 4) In addition to the RepositoryFactory implementation, I propose a
> simple wrapper Repository class that simply takes a URI like above as
> a constructor argument. This would make it really easy to connect to a
> repository:
> 
>     Repository local = new GenericRepository("file:///path/to/repository");
>     Repository remote = new GenericRepository("http://localhost:8080/");
> 
> The GenericRepository class would simply use the RepositoryFactory API
> under the hood.

This should also include the possibility to let go off the repository
(shutdown in case of a file:// URL and disconnect -- if required -- in
case of other URLs), right ?

Regards
Felix

[1] http://greenbytes.de/tech/webdav/rfc4709.html

> 
> BR,
> 
> Jukka Zitting
> 

Mime
View raw message