Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@gmail.com designates
 209.85.220.210 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=jPlxvPoTqAbq5lYD0v9JtGmgTthPr2O+1kLlEjO/F0fkCK8naChV00iTWx5V1W8Cxz
         lo8ShNlSMa0Xynmb/ELeHt45eT17wwtx1Lt+jjKkJXsxHfD9B9BMqLjs17TEVLqiJBUE
         Z27IBCUHkW1MxZMtV3Oi4KtaXzEp/shCxrA64=
Message-ID: <4AE01F6C.7090100@gmail.com>
Date: Thu, 22 Oct 2009 11:01:32 +0200
From: Felix Meschberger <fmeschbe@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: Generic JCR repository factory
References: <510143ac0910200811g1bf00847q7e43159b4d8b8de0@mail.gmail.com>
 <a781e7950910220127v56942990r861ad43bfbc752b3@mail.gmail.com>
In-Reply-To: <a781e7950910220127v56942990r861ad43bfbc752b3@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

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
Felix

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