On Tue, Nov 16, 2010 at 9:54 AM, Gunzenreiner Simon
<[email protected]> 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
