|
|
|
|
|
|
The JCR Content Hosting Handler (CHH) builds on the Content Hosting Handler plugin mechanism present in Sakai since v2.4. The CHH plugin mechanism allows external content repositories to be "mounted" within CHS so that the content external to Sakai becomes available within Resources. We already have read/write content hosting handlers for server filesystems, for DSpace, and for Fedora. A JCR CHH will make it possible to "mount" a JCR folder as a folder in CHS, and consequently makes the content within that folder available to any tool using CHS.
Technical DetailsThe JCR CHH will use the same mount mechanism as the existing ContentHostingHandler mount specifications. To mount a folder, a small XML file is uploaded to Resources. This file will contain the connection details to the JCR repository and the path into the repository. A property is set on the ContentResource that contains the XML file specifying the handler, and the XML file becomes a Virtual Content Collection.
The JCR CHH is shown connecting directly to JCRService. JCR CHH will need to use more of the JCR standard than is exposed through JCRNodeFactoryService, so it makes sense to go direct. It will still let JCRService manage the JCR transactions. However, this has the potential for Jackrabbit dependencies to creep in. The JCR CHH code will be written in such a way as to ensure multiple JCR implementation support. We will not allow Jackrabbit dependencies either by direct binding to Jackrabbit classes or out-of-band in the JCR CHH. The JCRService provided in Sakai 2.5 is a small wrapper that enables client code to get a javax.jrc.Session object from the JCR implementation deployed within Sakai. Clients of JCRService then use the standard JSR-170 API to perform all operations, having no more use for the JCRService. The JCR Session that is retrieved from JCRService knows about the Sakai environment and is bound to the request cycle, so that the programmer using JCRService does not have to think about transactions. This does put extra load on the developer since they now have to understand the JSR-170 API and need to understand how to use that API in a way that will work over most JCR implementations if they wish to preserve substitutability of JCR back-ends (a major business reason for introducing JCR). The reference implementation of JSR-170 is Apache Jackrabbit. In addition to being a RI, it goes much further than the standard, and could be used as a full XML database. The caveat is that a developer targeting Jackrabbit is likely to create an application that will not run on other JSR-170 compliant implementations. The JCR-CHS code has been written to target JSR-170 and does run on both Xythos and Jackrabbit. The JCRNodeFactoryService is based on this work. JCRNodeFactoryService will provide a limited number of simple methods to make it easier to interact with the JSR-170 API in a way that will work with multiple JCR repositories. It will provide methods to create JCR files and folders, find JCR files and folders, and stream the content of files both read and write. This service will also allow the developer to interact with a javax.jcr.Node which is part of the JSR-170 API. As such it will be possible to gain access to all of the JSR-170 API, and so a determined developer can still use the JCR in a way that might not work on full compliant JCR implementations like Xythos. Where the application developer does not want to bind to the standard javax.jcr.* API, there will be a Wrapper that allows the developer to bind to Sakai classes. This wrapper will hide the features of JCR and only expose a limited number of features. The wrapper will also ensure that the developer cannot create content which might not work in an alternative JCR implementation. If you want an API that enforces all the rules then you should use this Wrapper API. |
