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:[EMAIL PROTECTED] Sent: Wed 2/13/2008 11:10 AM To: [email protected] 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
