jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Generic JCR repository factory
Date Wed, 21 Oct 2009 16:51:56 GMT
Hi,

Thomas Müller schrieb:
> 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

I would not do relative paths, this becomes very unstable. Launching
code may prepare relative paths and turn them absolute. But the URI
given to the factory should/must be absolute.

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

This is an URL to connect to, so standards apply !

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

Please not a static method. This is IMHO not very good. If at all a
simple class with a single method, which may even be overwritten.

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

Is this only for RepositoryImpl ? Or this generically usable with the
new GenericRepository ? Why not add a good method to drop the repository
and have the implementation decide to (1) not do anything or (2) to shut
down or (3) to close the connection or (4) to sing hallelujah ...

Regards
Felix

> 
> Regards,
> Thomas
> 


Mime
View raw message