To expose WCM drives to the CMIS repositories, you must make a special extension of CmisRegistry.
To make a typical component org.exoplatform.ecms.xcmis.sp.jcr.exo.DriveCmisRegistry, do as follows:
<component>
<type>org.exoplatform.ecms.xcmis.sp.jcr.exo.DriveCmisRegistry</type>
<init-params>
<!-- Disabled by default. Uncomment if you need query support in CMIS. -->
<!-- value-param>
<name>indexDir</name>
<value>${gatein.jcr.index.data.dir}/cmis-index${container.name.suffix}</value>
</value-param-->
<value-param>
<name>exo.cmis.renditions.persistent</name>
<value>true</value>
</value-param>
<values-param>
<name>renditionProviders</name>
<description>Redition providers classes.</description>
<!-- <value>org.xcmis.renditions.impl.PDFDocumentRenditionProvider</value> -->
<value>org.xcmis.renditions.impl.ImageRenditionProvider</value>
</values-param>
</init-params>
</component>
Where configuration parameters include:
indexDir - directory where the lucene index will be placed. It is disabled by default.
exo.cmis.renditions.persistent - Indicates if a rendition of the document (thumbnails) should be persisted in the JCR. The allowed value are true or false.
renditionProviders - set of FQN of classes which can be used as Rendition Providers. Classes which implement the org.xcmis.spi.RenditionProvider interface are used to preview the CMIS objects (thumbnails).
In most cases, it is not required to change anything in the xCIMIS configuration. In case of any change of the indexer storage location, do not comment the indexDir value parameter and point it to the actual location.
The following configuration is mandatory for JCR to work correctly:
<external-component-plugins>
<target-component>org.exoplatform.services.jcr.RepositoryService</target-component>
<component-plugin>
<name>add.namespaces</name>
<set-method>addPlugin</set-method>
<type>org.exoplatform.services.jcr.impl.AddNamespacesPlugin</type>
<init-params>
<properties-param>
<name>namespaces</name>
<property name="cmis" value="http://www.exoplatform.com/jcr/cmis/1.0"/>
<property name="xcmis" value="http://www.exoplatform.com/jcr/xcmis/1.0"/>
</properties-param>
</init-params>
</component-plugin>
<component-plugin>
<name>add.nodeType</name>
<set-method>addPlugin</set-method>
<type>org.exoplatform.services.jcr.impl.AddNodeTypePlugin</type>
<init-params>
<values-param>
<name>autoCreatedInNewRepository</name>
<description>Node types configuration file</description>
<value>jar:/conf/cmis-nodetypes-config.xml</value>
</values-param>
</init-params>
</component-plugin>
</external-component-plugins>
An Authenticator is responsible for creating Identity Security Service Authenticator
The eXo CMIS service is based on:
The authentication mechanism provided by the eXo organization service.
The JAAS configuration of eXo Platform. For example,
gatein-domain {
org.exoplatform.web.security.PortalLoginModule required;
org.exoplatform.services.security.jaas.SharedStateLoginModule required;
org.exoplatform.services.security.j2ee.TomcatLoginModule required;
};
The CMIS standard defines a query language based on on a subset of the SQL-92 grammar (ISO/IEC 9075: 1992 -- Database Language SQL), with a few extensions to enhance its filtering capability for the CMIS data model, such as existential quantification for multi-valued property, full-text search, and folder membership.
CMIS search is disabled by default in eXo CMIS. Uncomment indexDir parameter if you need query support in CMIS. To discover search capability check capabilityQuery property (see table below).
The relational view of a CMIS repository consists of a collection of virtual tables that are defined on top of the CMIS data model. A virtual table exists for every queryable object type (content type if you prefer) in the repository. Each row in these virtual tables correspond to an instance of the corresponding object type (or of one of its subtypes). A column exists for every property that the object type has.
Table 2.1.
| Capability | Value |
| capabilityQuery | bothcombined (if indexDir configured, otherwise none) |
| capabilityJoin | none |
| capabilityPWCSearchable | false |
| capabilityAllVersionsSearchable | false |
To be able to provide full-text search capabilities xCMIS uses its own index. There is configuration parameter:
Table 2.2.
| Parameter | Default | Description |
| indexDir | none | The location of the index directory. This parameter is mandatory for default implementation |
All these parameters can be passed through the xml configuration.
How to set up the index directory.
<component>
<type>org.exoplatform.ecms.xcmis.sp.DriveCmisRegistry</type>
<init-params>
<!-- Disabled by default. Uncomment if you need query support in CMIS. -->
<!-- value-param>
<name>indexDir</name>
<value>${gatein.jcr.index.data.dir}/cmis-index${container.name.suffix}</value>
</value-param-->
..............
</init-params>
</component>Write-ahead logging
To be able to provide index consistency and recoverability in the case of unexpected crashes or damages, XCMIS uses write-ahead logging (WAL) technique. Write-Ahead Logging is a standard approach to transaction logging. Briefly, WAL's central concept is that changes to data files (indexes) must be written only after those changes have been logged, that is, when log records describing the changes have been flushed to permanent storage. If we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the index using the log: any changes that have not been applied to the data pages can be redone from the log records. (This is roll-forward recovery, also known as REDO.)
A major benefit of using WAL is a significantly reduced number of disk writes, because only the log file needs to be flushed to disk at the time of transaction commit, rather than every data file changed by the transaction.
Recover uncommited transaction
When you start Indexer, it will check uncommitted transaction logs. If there are at least one log exists - recover process will be started. Indexer will read all logs and extract added, updated and removed uuids into set. Then it will walk throw this set and check objects according to UUID. If object exist - indexer will put into the added documents list, in other case uuid will be added to removed documents list. After according to the list of added and removed documents changes will be applyed to the index.
Initial index population
When you run the indexer checks the number of documents in the index. If there is no documents in the index or previous re-indexation wasn't successful then re-indexation of all content will be started. First step is cleaning old index data. Uncommited transaction logs and old persistent data is removed. This data is useless, because re-indexation of all content will be started. Then indexer walks throw all objects and make lucene document for each one. Then batches with less then 100 elements will be saved to the index. After re-indexation, all logs (WAL) will be removed, all data mentioned on this changes logs - already indexed.
If administrator get exception with message "Can't remove reindex flag." it means that restore index was finished but file-flag was not removed ( see index directory, file named as "reindexProcessing"). You can manualy remove this file-flag, and avoid new reindex of repository on jcr start.