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

regards
 marcel

> BR,
>
> Jukka Zitting
>

Mime
View raw message