The J2EE Connector Architecture (JCA) is a mechanism by which applications can access all kinds of information systems in a controlled and coordinated manner. The JCA support included in application servers like Weblogic and JBoss takes care of managing things like connections, transactions and connection security on behalf of a client application. To do this, the application server leverages a JCA connector for the information system being accessed.

JCA is quite useful in many environments with complex integration requirements, so thanks to a community contribution, the Apache Jackrabbit project has been shipping a JCA connector since the 1.0 release. However, the Jackrabbit JCA connector was originally designed to run the Jackrabbit repository in embedded mode within the connector itself, only providing standard JCR API access to client applications. This made the connector design unsuitable for repositories like CRX that include a full suite of web-based management and editing tools that need access to repository internals. We worked around this issue with custom solutions for some CRX 1.x customers, but an improved JCA connector design was clearly needed.

Instead of implementing something for just CRX, we wanted to make a generic JCA connector for all JCR implementations and release it as open source. This way we'll return the favor to the community that contributed the original JCA connector code and will benefit from any improvements and fixes by the external contributors.

To improve the connector design, we turned to the RepositoryFactory interface introduced in JCR 2.0 and the Repository URI work we had done earlier. With these tools we could turn the existing Jackrabbit JCA connector from a Jackrabbit-specific tool to one that supports all JCR 2.0 implementations. This work was tracked in JCR-2555 and released as a part of Jackrabbit 2.1.0. You can find the resulting JCA resource archive (rar) file on the Jackrabbit download page.

To use the JCA connector with CRX on for example the JBoss application server, you first need install the CRX webapp following the normal installation documentation. Then deploy the Jackrabbit JCA rar file without modifications. Finally, as the last step you only need to connect these two resources together by deploying a connection factory descriptor like the one shown below:

<connection-factories>
  <tx-connection-factory>
    <jndi-name>jcr/crx</jndi-name>
    <xa-transaction/>
    <rar-name>jackrabbit-jca-2.1.0.rar</rar-name>
    <connection-definition>
      javax.jcr.Repository
    </connection-definition>
    <config-property name="repositoryURI"
      type="java.lang.String">
jndi://?org.apache.jackrabbit.repository.jndi.name=crx
&java.naming.factory.initial
=com.day.util.jndi.provider.MemoryInitialContextFactory
&java.naming.provider.url
=http://jcr.day.com
    </config-property>
    <config-property name="bindSessionToTransaction"
      type="java.lang.Boolean">true</config-property>
  </tx-connection-factory>
</connection-factories>


NOTE: The repositoryURI configuration property has been split to multiple lines for display. It needs to be all in one one in an actual descriptor file.

Set the jndi-name to the path under which you want the JCA-managed Repository instance to be available in the default JNDI context of the application server. Note also that you need to adjust the rar-name setting if you've deployed a different version of the Jackrabbit JCA rar file.

The diagram below illustrates how these different components work together:

The capability to expose a Java content repository through CMIS has been around for a while (see for example Day's announcement of a publicly available CMIS server). On the other hand, Apache Jackrabbit developer Michael Duerig has committed some code to the Jackrabbit sandbox that makes available a CMIS repository through JCR. Essentially, this allows you to connect to a CMIS repository and browse it with the JSR-170/283 API.

Being in the sandbox, this is for the adventurous to try by themselves. But if you want to: check out https://svn.apache.org/repos/asf/jackrabbit/sandbox/jackrabbit-spi2cmis/. You will need to have Apache Chemistry and Apache Jackrabbit installed (i.e. available in the local mvn repository) in order to build. Michael has put together some instructions in a README.

To understand how to use the code have a look at the test cases. In particular, in AbstractTestCase.java there are test setups for the public CMIS repositories of Day, Alfresco and Nuxeo.

From the Jackrabbit web site:

January 27, 2010: Apache Jackrabbit 2.0.0 released

Apache Jackrabbit 2.0.0 is a fully compliant and production-ready implementation of JCR 2.0.

Get it while it's hot.

Justin Cormack has written a noteable blog post titled "RESTful daydream #4" (pun intended?) about RESTful content repositories. I disagree with some of what Justin writes about JCR and Sling. However, I completely share his vision about REST's role in content management and I am with him regarding the overall theme of his post.

Essentially, Justin asks for a "web content repository":

The odd thing is that a web content repository alone surely lends itself to a simple REST architecture. Content is after all lots of small resources with relations. [...] It takes content, relates it to other content, and serves it back, with authentication and versioning. Everything else is in other system layers, transforming it and so on. Not simple, but well defined; lower level than JCR + Sling say.

Apache Sling provides a RESTful interface onto content, but being a web application framework it provides much more, especially scripting. So I can understand well why Justin dismisses Sling as being too powerful. However, I believe that Jackrabbit's native http layer is pretty much on the mark (Justin also dismisses it in the comments as being not RESTful. I do not know why.). As far as I know the Jackrabbit http remoting layer is quite work-in-progress so one might argue about the details regarding its RESTfulness, but overall it fits what I understand to be a RESTful web content repository.

There is one aspect regarding a web content repository I would like to add to the discussion: I think it is crucial that the representations of resources and be consumed by browsers. HTML forms for writing and presenting resources in JSON should be part of the equation. Adding models or semantics on top of that will might do more harm than good.

Do we need a formal standard for web content repositories? From my perspective: not yet. At the moment we still need to learn more, i.e. more repository implementations and users that have built a CMS on top of a web content repository.