jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Generic JCR repository factory
Date Thu, 22 Oct 2009 10:32:03 GMT

On Thu, Oct 22, 2009 at 10:27 AM, Marcel Reutegger
<marcel.reutegger@gmx.net> wrote:
> I might be missing something but isn't much of this already covered
> with the existing JCR RepositoryFactory interface and our
> implementations thereof?

The stuff that's not covered is how you actually get the
RepositoryFactory references. I'm looking for a utility class (or
method) that hides the Service Provider lookup code from the client.

> I don't see a need to move around stuff, [...]

The reason for moving stuff around is that there's little point in
having the jackrabbit-jcr-client class consist of just a single class
that depends on nothing but the JCR API. We could just as well have it
in jackrabbit-jcr-commons.

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

Something like this perhaps:

    Repository getRepository(String uri) throws RepositoryException {
        Map<String, String> parameters = new HashMap<String, String>();
        // convert URI to parameters accepted by known RepositoryFactories

        Iterator<RepositoryFactory> iterator =
        while (iterator.hasNext()) {
            RepositoryFactory factory = iterator.next();
            Repository repository = factory.getRepository(parameters);
            if (repository != null) {
                return repository;

        throw new RepositoryException(
                "No repository implementation is available for the URI " + uri);

How about if we made this a part of the JcrUtils class in

    Repository repository = JcrUtils.getRepository("http://localhost:8080/");

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

The only problem I see with this is that there's nothing to prevent
another RepositoryFactory implementation from accepting that same map,
in which case the behaviour of the proposed code above becomes highly
dependant on classpath ordering.

I guess we can avoid that problem by explicitly expecting that no
RepositoryFactory implementation will not simply assume default values
if the configuration settings it expects are not found in the given
property map. That expectation is reasonably well grounded in the spec
saying: "The implementation must return null if it does not understand
the given parameters."


Jukka Zitting

View raw message