jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: Generic JCR repository factory
Date Wed, 21 Oct 2009 12:31:09 GMT

> The current jackrabbit-jcr-client component contains a RepositoryFactory implementation

Yes, and only this class. Can we get delete this component, or what
are the plans?

>> 1) Is there a reason why this generic RepositoryFactory implementation
>> couldn't go to jackrabbit-jcr-commons?

This component doesn't have a dependency to core. The factory could
use reflection to get the right implementation, or use the service
provider mechanism (java.util.ServiceLoader /
javax.imageio.spi.ServiceRegistry), or we could use an optional

>> 3) How about using URIs as a simple configuration mechanism?

That would be great. I wonder: is there a standard for the "//" after
"file:"? If not I would use:


For http the the situation is different because there are no relative
paths, so the standard ("http://") should be required.

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

Instead of a new class with a constructor, I would add a static method
to the factory:

Repository rep = RepositoryFactory.getRepository("http://localhost:8080");

Reasons: a static method can return a different instance (a
JackrabbitRepository, a AcmeRepository, whatever), whereas with "new
GenericRepository" the options are _very_ limited.

> This should also include the possibility to let go off the repository
> (shutdown in case of a file:// URL and disconnect -- if required -- in
> case of other URLs), right ?

We do have an API for shutdown now: RepositoryManager.stop(). I know
it's quite painful to use... but I guess we should stick with that
now. If we want to simplify using it, at least we should find a
solution that doesn't break compatibility.


View raw message