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 <[email protected]> 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 >> >
