jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Gash" <Simon.G...@gossinteractive.com>
Subject RE: implementation independent repository lookup
Date Tue, 13 Sep 2005 15:25:50 GMT
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.


-----Original Message-----
From: Michael Wechner [mailto:michael.wechner@wyona.com] 
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


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
> JCR implementations as well.

thanks for the code snippets


> BR,
> Jukka Zitting

Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org

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

View raw message