You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2008/02/12 14:10:59 UTC
Repository factory, was: SPI caching, was: [jira] Resolved: (JCR-1361)
Lock testassumesthat changes in one session are immediately visible in differentsession
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
RE: Repository factory, was: SPI caching, was: [jira] Resolved:(JCR-1361) Lock testassumesthat changes in one session are immediatelyvisible in differentsession
Posted by David Rauschenbach <Da...@SYNCHRONICA.COM>.
Another one of the areas with potential for performance improvement is in JCR2SPI. Sometimes fetching a node will cause getItemInfos to be called, which can return all the properties for a node at once, which is great. But other times, the JCR client calling code might access 8 properties, and it results in 8 separate getPropertyInfo calls instead of a single getItemInfos call. That is one area where I am trying to put adaptive code into my SPI's, to intercept the getPropertyInfo at some point and invoke getItemInfos instead. I don't know what, if any of this, could end up in JCR2SPI as a generalized solution, but I'll be keeping it in mind.
David
-----Original Message-----
From: David Rauschenbach
Sent: Tue 2/12/2008 3:50 PM
To: dev@jackrabbit.apache.org
Subject: Re: Repository factory, was: SPI caching, was: [jira] Resolved:(JCR-1361) Lock testassumesthat changes in one session are immediatelyvisible in differentsession
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
Visit Synchronica at GSMA Mobile World Congress, Barcelona, 11-14 Feb, Hall 2, Booth #2J25
Re: Repository factory, was: SPI caching, was: [jira] Resolved:(JCR-1361) Lock testassumesthat changes in one session are immediatelyvisible in differentsession
Posted by David Rauschenbach <da...@synchronica.com>.
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