jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Rauschenbach" <david.rauschenb...@synchronica.com>
Subject Re: Repository factory, was: SPI caching, was: [jira] Resolved:(JCR-1361) Lock testassumesthat changes in one session are immediatelyvisible in differentsession
Date Tue, 12 Feb 2008 14:50:06 GMT
 
Yes I use a custom RepositoryConfig, and implement bean methods there
for custom configuration, as it applies to whatever the repository is.
But, there's no way to remote a serialized RepositoryConfig over SPI, to
do the factory work at the remote end, if you know what I mean. Again,
just because the spec doesn't address how to do the configuration and
factory work doesn't mean it doesn't have to happen. That's where some
flexibility in SPI is needed, so that it can allow someone to write a
proxy, or gateway, or middleware of whatever sort.

Sorry I was not clear about the repository descriptors. Yes you're right
you can ask for descriptors without credentials, but that's the same
reason you could never make that call to an SPI web service that used
container-managed security, to get those descriptors, because during
such a call the credentials are not yet known. This could be fudged, if
it were not for the fact that JCR2SPI asks for the descriptors before
attempting a login, even though I seem to recall examining the code and
seeing it had no pressing need for those descriptors until after login,
when nodes were being dealt with.

David



On Tue, 2008-02-12 at 14:10 +0100, Julian Reschke wrote:
> 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
> 
> 

 
Visit Synchronica at GSMA Mobile World Congress, Barcelona, 11-14 Feb, Hall 2, Booth #2J25
 
 

Mime
View raw message