You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2010/12/11 15:48:39 UTC
Re: AW: Replacing jackrabbit with other JCR implementation
Hi,
Am Mittwoch, den 08.12.2010, 20:29 +0100 schrieb Gunzenreiner Simon:
> Hi Clemens
>
> Sorry for the late answer: We will look into this in the next few weeks. We ModeShape is deployed a Tomcat embedded in JBoss, but we control the lifecycle of modeshape ourselves (so it's not bound to JNDI or not deployed as a JBoss service). We basically create the repository with the standard JCR 2.0 API:
>
> RepositoryFactory factory = ServiceLoader.load(RepositoryFactory.class));
> Repository repository = factory.getRepository(parameters);
I start wondering whether we could implement extender pattern support
for the JCR RepositoryFactory ?
This extender would check all bundles for the
"META-INF/services/javax.jcr.RepositoryFactory" file and register the
RepositoryFactory instances internally.
Upon factory configuration the registered factories would be presented
the configuration properties and the first repository returned by one of
the factories would then be registered as the Repository service for
this configuration.
WDYT ?
Regards
Felix
>
> Regards
> Simon
>
> -----Ursprüngliche Nachricht-----
> Von: Clemens Wyss [mailto:clemensdev@mysign.ch]
> Gesendet: Dienstag, 23. November 2010 10:23
> An: users@sling.apache.org
> Betreff: AW: Replacing jackrabbit with other JCR implementation
>
> Hi Simon,
> are you working on ModeShape@Sling?
> Do you have a "standalone" (i.e. without JBOSS,Tomcat) ModeShape setup? JPA Connector?
>
> Regards
> Clemens
>
> > -----Ursprüngliche Nachricht-----
> > Von: Gunzenreiner Simon [mailto:simon.gunzenreiner@axa-tech.com]
> > Gesendet: Dienstag, 16. November 2010 09:55
> > An: users@sling.apache.org
> > Betreff: Replacing jackrabbit with other JCR implementation
> >
> > Hi all
> >
> > I am looking into replacing the embedded Jackrabbit JCR implementation
> > with another JCR 2.0 implementation (Modeshape). This should be possible
> > in principle, right? What functionality in Sling is depending on Jackrabbit as a
> > repository?
> >
> > I would appreciate any hints or guidance of how to achieve this and what
> > pitfalls to avoid.
> >
> > Best regards
> > Simon
Re: Replacing jackrabbit with other JCR implementation
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 13.12.2010, 13:28 +0100 schrieb Bertrand Delacretaz:
> On Mon, Dec 13, 2010 at 12:58 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> > Felix Meschberger wrote
> >
> >> I start wondering whether we could implement extender pattern support
> >> for the JCR RepositoryFactory ?
> >>
> >> This extender would check all bundles for the
> >> "META-INF/services/javax.jcr.RepositoryFactory" file and register the
> >> RepositoryFactory instances internally.
> >>
> >> Upon factory configuration the registered factories would be presented
> >> the configuration properties and the first repository returned by one of
> >> the factories would then be registered as the Repository service for
> >> this configuration.
> >>
> >
> > This sounds interesting, but what about the parameters passed into the
> > javax.jcr.RepositoryFactory? Would we rely on default props?
>
> IIUC what Felix means is that, once the various RepositoryFactory are
> registered, you need to create an OSGi config that one of them
> understands. That config is passed to all registered
> RepositoryFactory, and the first one that returns a Repository wins.
Exactly.
Regards
Felix
>
> -Bertrand
Re: Replacing jackrabbit with other JCR implementation
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Dec 13, 2010 at 12:58 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Felix Meschberger wrote
>
>> I start wondering whether we could implement extender pattern support
>> for the JCR RepositoryFactory ?
>>
>> This extender would check all bundles for the
>> "META-INF/services/javax.jcr.RepositoryFactory" file and register the
>> RepositoryFactory instances internally.
>>
>> Upon factory configuration the registered factories would be presented
>> the configuration properties and the first repository returned by one of
>> the factories would then be registered as the Repository service for
>> this configuration.
>>
>
> This sounds interesting, but what about the parameters passed into the
> javax.jcr.RepositoryFactory? Would we rely on default props?
IIUC what Felix means is that, once the various RepositoryFactory are
registered, you need to create an OSGi config that one of them
understands. That config is passed to all registered
RepositoryFactory, and the first one that returns a Repository wins.
-Bertrand
Re: Replacing jackrabbit with other JCR implementation
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote
> I start wondering whether we could implement extender pattern support
> for the JCR RepositoryFactory ?
>
> This extender would check all bundles for the
> "META-INF/services/javax.jcr.RepositoryFactory" file and register the
> RepositoryFactory instances internally.
>
> Upon factory configuration the registered factories would be presented
> the configuration properties and the first repository returned by one of
> the factories would then be registered as the Repository service for
> this configuration.
>
This sounds interesting, but what about the parameters passed into the
javax.jcr.RepositoryFactory? Would we rely on default props?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org