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 Thu, 22 Oct 2009 09:01:32 GMT

Marcel Reutegger schrieb:
> Hi,
> 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.

We *always* need some kind of lifecycle: Even if you just *connect* to a
repository, you want to be able to explicitly *disconnect* from the
repository -- and don't tell me "stop the application to disconnect" ;-)


> regards
>  marcel
> 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