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