jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Generic JCR repository factory
Date Thu, 22 Oct 2009 08:27:14 GMT

I might be missing something but isn't much of this already covered
with the existing JCR RepositoryFactory interface and our
implementations thereof?

I don't see a need to move around stuff, we just need a utility method
(which usually happen to be static ;) ) that turns a defined set of
URLs into a parameter map that is consumed by the RepositoryFactory
implementations. Those implementations can all be discovered using the
standard Java Service Provider mechanism. There is no need to declare
dependencies for that.

e.g. to access a repository on the file system, the utility method had
to translate the URL file:///my/repo/home into a map with:
- org.apache.jackrabbit.repository.home -> file:///my/repo/home
- org.apache.jackrabbit.repository.conf -> file:///my/repo/home/repository.xml

with this map content, the
org.apache.jackrabbit.core.RepositoryFactoryImpl will provide a
repository instance.

and btw. that's a TransientRepository, so you don't even have to care
about life cycle :)
for all the other RepositoryFactory implementations you probably don't
need life cycle anyway because you only *connect* to an already
running repository and don't start it.


On Tue, Oct 20, 2009 at 17:11, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.
> 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.
> BR,
> Jukka Zitting

View raw message