jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: JCR-RMI, SPI, WEBDAV, and Sling's REST
Date Tue, 24 Nov 2009 08:21:18 GMT
On Mon, Nov 23, 2009 at 23:09, ChadDavis <chadmichaeldavis@gmail.com> wrote:
> Depending upon my use case . . . but this is clearly not a use case
> for accessing the JCR API in my application's code, correct?

No, it doesn't provide the full JCR API. But it allows for simple
content creation and access through eg. Ajax clients.

>>> I want to know what my options are for deploying jackrabbit in it's
>>> own JVM, then connecting to it and coding agains the JCR API.  Does
>>> SPI provide this?  Surely, I can't get this from WEBDAV or Sling, can
>>> I?
>> There are two Webdav implementations in Jackrabbit: one is the simple
>> webdav server which presents the repository like a file system, with
>> built-in support for nt:folder and nt:file and customizable handlers
>> for other nodetypes.
> Is the use case for this a webdav client browser?  Can you provide a
> reference to this simple webdav server by it's Jackrabbit component
> name, or maven module?

The simple webdav server - should probably better named file-based
webdav - is mainly used to mount the repository as a filesystem in
your operating system. Works well on Linux and MacOSX, but also under
Windows, although some people seem to prefer special webdav clients
for that environment as the default client does not provide a full

>> The other Webdav is the JCR webdav server, which provides the full JCR
>> API capabilities if used by a jcr2spi + spi2dav client setup. SPI =
> How is this webdav server supposed to differ from the one mentioned
> above?  Is it meant to be used to remote the repository via JCR (
> though the spi packages you mention above ), or is this just an add
> on?

It provides all JCR operations. This is - afaiu - what you are looking
for. They are completely separated, this one has its endpoint at
/server, whereas the file-based simple webdav server is at
/repository/<workspace> (in the jackrabbit-webapp).

>> service provider interface (yes, a quite generic name) is a simpler
>> version of the JCR API with the possibility of batch operations,
>> useful for improving performance over remoting. There is a generic
> In what way is this a simpler version of the API?  Specifically, my
> application will need to make use of read, write of nodes, workspace
> operations, and version control.  Are these things supported?

It's a proprietary shortened API, but supporting all JCR operations.
But you don't have to code against it, I just wanted to explain the
underpinnings of this setup.

>> jcr2spi client that maps the JCR API onto the spi API. The spi2dav is
>> an spi API implementation that connects to the JCR webdav server,
>> which itself sits on top of the actual Jackrabbit repository (using
>> the JCR API itself).
> So, I would use the jcr2spi in my application, the client code if you
> will.  And then I would use spi2dav on the webdav server?


> I had read that SPI was supposed to supplant the poorly performing
> JCR-RMI remoting.

More or less... as noted, SPI is better for building a remote protocol
because it allows batch operations. There is an spi-rmi for example,
that should (I haven't used it myself) in theory be already better
than jcr-rmi. This would be because of the reduced property read etc.
operations. But with RMI in general the protocol is very noisy as
every method call maps to a network roundtrip.

Hence the spi2dav(ex) was built on top using HTTP/Webdav and JSON
rendering for a more efficient and readable protocol.

> Is SPI only available as a layer over webdav?

No, see the link I sent earlier:
http://jackrabbit.apache.org/jackrabbit-spi.html There is a spi2jcr
for example, which maps the spi api back to jcr.

> Thanks Alex.  BTW, it seems like I'm going against the tide by trying
> to deploy my JCR as a data tier / remote resource to my application.
> Is this true?

With unstructured storages and CMS use-cases (which are typical for
JCR) replication of content is much more normal than it is with the
traditional one-big-sql-database-for-everything approach. So often you
find a webapp with a local JCR repository and that's it. To provide
fail-over, Jackrabbit allows for clustering.


Alexander Klimetschek

View raw message