David Rauschenbach wrote:
I should have elaborated on the Repository factory problem.

Let's say someone implements the
org.apache.jackrabbit.commons.repository.RepositoryFactory interface.
They might have some constructor arguments, or some bean setters, for
setting properties like target host and protocol in a corba or web
service, or whatever.

Instantiating such a factory via Spring might look like this:

  <bean id="repoFactory" class="MyFactory">
    <property name="uri" value="iiop://server1/svc"/>
    <property name="debug" value="true"/>
  </bean>

  <bean id="repo"
    factory-bean="repoFactory"
    factory-method="getRepository"
  </bean>

So, the proprietary setter methods of the factory (setDebug(boolean) and
setUri(String)) have to pass over the SPI, in order to instantiate the
target Repository that is to be used by SPI2JCR.

Hm. Right now you can implement a RepositoryConfigFactory with the same pattern, and then pass a RepositoryConfig with the right settions to JCR2SPI for creation of a Repository. Am I missing something?

And all that has to be able to happen when or before getDescriptors gets
called, which JCR2SPI calls before login.

In other words:

  1. You call getDescriptors on the repository, not the session. SPI
needs to reflect that.

In SPI, the method is on RepositoryService and is not related to SessionInfo, so it is already that way, isn't it?

  2. Repository factories and configuration are not addressed by JSR170, but 
SPI has to allow it to occur anyway.

Nice to have? Yes. Necessary? Not sure.

Could you please explain what you can't do today? You have full control over your implementation of RepositoryConfig, doesn't this give you the necessary flexibility?

BR, Julian


Reply via email to