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: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumesthat changes in one session are immediately visible in differentsession
Date Wed, 13 Feb 2008 17:10:19 GMT
 
Thanks for mentioning that JSR283 mechanism. Suddenly the TCK makes a little more sense to
me. My colleague says we will pay a price for using JNDI, since everything coming out of the
Repository will have to get serialized and then deserialized back again? I suppose I'll just
pay the price (5% ??), and leave the debate to the Spring versus J2EE crowd. It will be nice,
though, to deploy repository impl's as stand-alone WAR files.

David
-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
Sent: Wed 2/13/2008 11:10 AM
To: dev@jackrabbit.apache.org
Subject: Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumesthat changes in
one session are immediately visible in differentsession
 
David Rauschenbach wrote:
> In other words:
> 
>   1. You call getDescriptors on the repository, not the session. SPI
> needs to reflect that.

that's why you can call RepositoryService.getDescriptors() without a SessionInfo.

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

so far we did not deal with initialization of an SPI implementation, but feel 
free to suggest a factory mechanism.

please note, that JSR 283 introduces a standard way how to obtain a repository 
instance though a fectory mechanism.

regards
  marcel


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

Mime
  • Unnamed multipart/mixed (inline, 7-Bit, 0 bytes)
View raw message