You don't need to extend it. Spring allows you to create factory beans (like the jeceira stuff) or you can use a mapping like the one below for your jackrabbit.
I've set up an implementation independent start up, the dependency is provided purely by the spring configuration file. I've got unit tests running for both Jeceira and JackRabbit. I've had to write no code at all just a fancy configuration file. Si -----Original Message----- From: Michael Wechner [mailto:[EMAIL PROTECTED] Sent: 13 September 2005 15:59 To: jackrabbit-dev@incubator.apache.org Subject: Re: implementation independent repository lookup > Michael Wechner wrote: > >>> Are you looking for something like the DriverManager in JDBC? >> >> >> yes, I guess something like >> >> jcr.drivers=org.apache.jackrabbit.Driver:com.jeceira.Driver >> >> but I assume that JCR would have to enhance the API, right? Also >> I guess the various implementations would have to find consensus on >> how the configuration is being loaded or rather the API would impose >> that on them I guess. > > > Yes. Either extend the API or create some other de facto repository > instantiation standard. However I think that this issue is better > handled by the various component frameworks than a JCR-specific API. why do you think so? Doesn't that mean that each who wants to switch between JCR implementations will have to implement it themselves, whereas something like javax.jcr.RepositoryFactory.getRepository() would "force" implementation "free" code? > > >>> I was thinking about proposing such a mechanism sometime ago, but >>> I've since settled on using JNDI in container environments and >>> Spring (or another component framework) in standalone applications. >> >> >> do you have some code snippets how this can be done without using for >> instance the jackrabbit specific RegistryHelper? > > > I've been using something like the following with the Spring framework > to avoid a direct Jackrabbit dependency in standalone applications: > > ApplicationContext context = ...; > Repository repository = (Repository) > context.getBean("repository", Repository.class); > > The current Jackrabbit core classes are not very Spring-friendly, but > the following sample bean configuration should give you a configured > Jackrabbit Repository instance as the "repository" bean: > > <bean id="repository-config" > class="org.apache.jackrabbit.core.config.RepositoryConfig" > factory-method="create"> > <constructor-arg type="java.lang.String" index="0"> > <value>/path/to/repository.xml</value> > </constructor-arg> > <constructor-arg type="java.lang.String" index="1"> > <value>/path/to/repository</value> > </constructor-arg> > </bean> > > <bean id="repository" > class="org.apache.jackrabbit.core.RepositoryImpl"> > <constructor-arg> > <ref local="repository-config"/> > </constructor-arg> > </bean> > > It should be possible to create similar configuration snippets for other > JCR implementations as well. thanks for the code snippets Michi > > BR, > > Jukka Zitting > > -- Michael Wechner Wyona - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED] Come visit us at: Content Management Europe Exhibition. 29th November - 1st December 2005, Olympia Grand Hall, London. Stand # 341 GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte Technology Fast 500 EMEA. This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. Email transmission cannot be guaranteed to be secure or error free, as information may be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This email and any files attached to it have been checked with virus detection software before transmission. You should nonetheless carry out your own virus check before opening any attachment. GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software viruses.
