You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Gunzenreiner Simon <si...@axa-tech.com> on 2010/11/16 09:54:58 UTC
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 Bertrand Delacretaz <bd...@apache.org>.
On Tue, Nov 16, 2010 at 9:54 AM, Gunzenreiner Simon
<si...@axa-tech.com> wrote:
> ...I am looking into replacing the embedded Jackrabbit JCR implementation
> with another JCR 2.0 implementation (Modeshape). This should be possible
> in principle, right? ...
In theory yes, if Modeshape passes the TCK.
But I think ATM all Sling users are using Jackrabbit, so that will
probably not work out of the box.
> ...What functionality in Sling is depending on
> Jackrabbit as a repository?...
The org.apache.jackrabbit.jackrabbit-api bundle provides
Jackrabbit-specific extensions to the JCR API, and if you look at
which bundles use it (in the OSGi console) you get:
Importing Bundles:
org.apache.sling.auth.openid (13)
org.apache.sling.extensions.webconsolesecurityprovider (67)
org.apache.sling.jcr.base (50)
org.apache.sling.jcr.contentloader (24)
org.apache.sling.jcr.jackrabbit.accessmanager (52)
org.apache.sling.jcr.jackrabbit.server (53)
org.apache.sling.jcr.jackrabbit.usermanager (54)
Of those, org.apache.sling.jcr.base and
org.apache.sling.jcr.contentloader, at least, look problematic.
The latter is in turn imported by the org.apache.sling.servlets.post
which shouldn't be required - might need some refactoring to avoid
that.
>
> ...I would appreciate any hints or guidance of how to achieve this and what
> pitfalls to avoid....
In theory, you need to replace the
org.apache.sling.jcr.jackrabbit.server bundle with your own, that
provides a SlingRepository service, and - I think - remove the
org.apache.jackrabbit.jackrabbit-api bundle as Modeshape probably
doesn't provide those extensions.
This will break a number of things, most of which should be optional
but as shown above there are some unwanted dependencies that need to
be cleaned up. Contributions are welcome of course, as I don't think
anyone's working on that at the moment.
-Bertrand
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
Re: AW: Replacing jackrabbit with other JCR implementation
Posted by Felix Meschberger <fm...@gmail.com>.
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
AW: Replacing jackrabbit with other JCR implementation
Posted by Gunzenreiner Simon <si...@axa-tech.com>.
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);
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
AW: Replacing jackrabbit with other JCR implementation
Posted by Clemens Wyss <cl...@mysign.ch>.
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 Justin Edelson <ju...@justinedelson.com>.
On Tue, Nov 16, 2010 at 4:54 AM, Felix Meschberger <fm...@gmail.com> wrote:
> One thing that may break is the node type loading functionality of the
> jcr/base bundle. This uses Jackrabbit API which is not standardized
> (There is in fact an old issue to replace this implementation with an
> implementation leveraging the official JCR node type management API).
This is no longer true. Node Type loading now uses classes from
jackrabbit-jcr-commons which should work against any JCR 2
implementation. The bits in jcr.base which *are* dependent upon
Jackrabbit are in AccessControlUtil (actually, there's one more
reference in AbstractSlingRepository, but that doesn't need to be
there and I'll commit a fix soonish). We could probably make the
import of o.a.jackrabbit.* optional for jcr.base.
In general, this is probably true across the board - anything related
to access control (i.e. ACL loading in content loader) is dependent
upon Jackrabbit. Everything else *should* be JCR only.
Of course, it'd be great to have someone actually test this out with
ModeShape or another non-Jackrabbit (or CRX) implementation.
Justin
Re: Replacing jackrabbit with other JCR implementation
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 16.11.2010, 09:54 +0100 schrieb Gunzenreiner Simon:
> 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?
Interesting idea ;-)
>
> I would appreciate any hints or guidance of how to achieve this and what
> pitfalls to avoid.
First off this should be possible. Basically it is just about replacing
jackrabbit-server bundle with your own bundle providing the
repository ...
You might want to use the jackrabbit-server bundle as a role-model.
One thing that may break is the node type loading functionality of the
jcr/base bundle. This uses Jackrabbit API which is not standardized
(There is in fact an old issue to replace this implementation with an
implementation leveraging the official JCR node type management API).
Two other things, that may break are the jcr/jackrabbit.usermanager
jcr/jackrabbit.accessmanager bundles.
Other than that, I would expect Sling to work properly with just about
any JCR 2.0 (most operations event only require JCR 1.0) compliant
repository.
If you stumble upon any issues, don't hesitate to ask !
If you succeed, don't hesitate to share your findings ;-)
Regards
Felix