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 15:57:34 GMT
On Thu, Oct 22, 2009 at 12:32, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> 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.

I agree about the jackrabbit-jcr-client. I never liked that module anyway ;)

I was referring to the discussion about merging the other modules.

>> 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 =
>            ServiceRegistry.lookupProviders(RepositoryFactory.class);
>        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
> jackrabbit-jcr-commons:
>    Repository repository = JcrUtils.getRepository("http://localhost:8080/");

exactly what I was thinking of.

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

right. and I would expect that RepositoryFactory implementations will
use namespaced keys in the map, as proposed in the spec:

"The keys are not specified by JCR and are implementation specific.
However, vendors should use
keys that are namespace qualified in the Java package style to
distinguish their key names."


> BR,
> Jukka Zitting

View raw message