Hi,
> 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
dependency.
>> 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:
file:relativePath
file:/absolutePath
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.
Regards,
Thomas
