A March 2005 white paper on “The Hidden Costs of Information Work” by the IDC in the United States found that the average office employee spent approximately one day per week organizing and filing documents that they used. This can equate to a considerable amount of cost and inefficiency. A further twelve hours was spent on managing document approval, managing document routing and publishing to other channels. Nine hours was spent searching for documents.

Nuxeo EP 5 is the 5th version of the open source platforms developed by Nuxeo (the four previous ones where known as "CPS").

Nuxeo EP or "Enterprise Platform" is the server part of Nuxeo EP 5. It is a Java EE application intended to run in a standard Java EE 5 application server like JBoss. It can be accessed by end users from a web browser, from office productivity suites like MS-Office or OpenOffice.org, or from rich client developed using the Nuxeo RCP technology (see below).

Nuxeo RCP or "Rich Client Platform" is a platform for building rich client applications, that usually connect to a Nuxeo EP server.

Nuxeo EP and Nuxeo RCP run on top of a common runtime, "Nuxeo Runtime", and share a common set of core components, called "Nuxeo Core".

When we started building Nuxeo EP, we defined several goals to achieve. Because these goals have a structural impact on Nuxeo EP platform it is important to understand them: it helps understanding the logic behind the platform.

All the design goals explained just before have a huge impact on the Nuxeo EP architecture. Before going into more details, here are the main concepts of Nuxeo EP architecture.

Building the Nuxeo Runtime was one of the first tasks we started. This is one of the main infrastructure components of the Nuxeo EP architecture.

This section will give you a quick overview of the Nuxeo Runtime. A more detailed technical presentation can be found in ??? of this book.

Nuxeo Runtime provides the component model for the platform.

This component model is heavily based on OSGi and provides the following features:

Nuxeo Runtime also provides deployment services to manage how components are deployed and contribute to each other

Here is a simple example of a deployment-fragment.

<fragment>
  <extension target="application#MODULE">
    <module> <ejb>${bundle.fileName}</ejb> </module>
  </extension>
  <extension target="faces-config#VALIDATOR">
    <validator>
      <validator-id>dueDateValidator</validator-id>
      <validator-class>org.nuxeo.ecm.platform.workflow.web.ui.jsf.DueDateValidator</validator-class>
    </validator>
  </extension>
  <install>
    <!-- unzip the war template -->
    <unzip from="${bundle.fileName}" to="/">
      <include>nuxeo.war/**</include>
    </unzip>
    <!-- create a temp dir -->
    <!-- be sure no directory with that name exists -->
    <delete path="nxworkflow-client.tmp" />
    <mkdir path="nxworkflow-client.tmp" />
    <unzip from="${bundle.fileName}" to="nxworkflow-client.tmp">
      <include>OSGI-INF/l10n/**</include>
    </unzip>
    <append from="nxworkflow-client.tmp/OSGI-INF/l10n/messages.properties"
               to="nuxeo.war/WEB-INF/classes/messages.properties" addNewLine="true" />
    <append from="nxworkflow-client.tmp/OSGI-INF/l10n/messages_en.properties"
               to="nuxeo.war/WEB-INF/classes/messages_en.properties" addNewLine="true" />
    <append from="nxworkflow-client.tmp/OSGI-INF/l10n/messages_fr.properties"
               to="nuxeo.war/WEB-INF/classes/messages_fr.properties" addNewLine="true" />
    <append from="nxworkflow-client.tmp/OSGI-INF/l10n/messages_de.properties"
               to="nuxeo.war/WEB-INF/classes/messages_de.properties" addNewLine="true" />
    <append from="nxworkflow-client.tmp/OSGI-INF/l10n/messages_it.properties"
               to="nuxeo.war/WEB-INF/classes/messages_it.properties" addNewLine="true" />
    <delete path="nxworkflow-client.tmp" />
  </install>
</fragment> 

Nuxeo EP components are separated in 3 main layers: Core / Service / UI

From the logical point of view each layer is a group of components that provide the same nature of service:

The layer organization can also be seen as a deployment strategy

Thanks to the Nuxeo Runtime remoting features it is very easy to split the components on several JVMs. But splitting some services can have a very bad effect on the global system performance.

Because of this, all the storage oriented services are inside the core. All components that have extensive usage of the repository and need multiple synchronous interaction with it are located in the core. This is especially true for all synchronous event handlers.

The services layer can itself be split in multiple deployment units on multiple JVMs.

On the UI side all the services are logically deployed inside the same JVM. At least each JVM must have the minimum set of services to handle user interaction for the given application.

The components are also grouped by layers according to their dependencies.

Core Modules can depend on Core Internal API.

Generic ECM services can depend on Core external API and can depend on external optional library (like jBPM, Jena, OpenOffice.org ...).

UI services can rely on a client side API (like Servlet API) and share a common state associated to the user session.

Layers are also organized according to deployment target.

The Core layer is a POJO Layer with an optional EJB facade. The core can be embedded in a client application.

The services are mostly implemented as POJO services so that they can be used as an embedded library. But some of them can depend on typical Application Server infrastructure (like JMS or EJB).

Inside the UI Layer most services are dedicated to a target platform: web (JSF/Seam), Eclipse RCP or other.

Because the layer organization has several constraints, the implementation of a unique feature is spread across several layers.

Typically a lot of these "transverse services" are split into several sub-components in each layer in order to comply with deployment constraints and also to provide better reusability. For example, the Audit service is made of 3 main parts which are split across 3 layers:

The layer organization can also be seen in the API.

Nuxeo core provides all the storage services for managing documents.

The repository enforces data integrity and consistency based on Document types definition.

Each document type is defined by:

Here is a simple DocumentType declaration:

<extension target="org.nuxeo.ecm.core.schema.TypeService"
    point="doctype">
    <documentation>The core document types</documentation>
    <doctype name="Folder" extends="Document">
      <schema name="common" />
      <schema name="dublincore" />
      <facet name="Folderish" />
    </doctype>
    </extension>

For further explanation on Schemas and Document types, please see ???.

Inside the Nuxeo repository each document may be associated with a life-cycle. The life-cycle defines the states a document may have and the possible transitions between these states. Here we are not talking about workflow or process, rather we are just defining the possible states of a document inside the system.

The Nuxeo Core contains a LifeCycleManager service that exposes several extension points:

Life-Cycle service is detailed later in this document (??? and ???).

Note: You may also want to read the chapter on "Access Control and Security" in the Learning Nuxeo EP5 Guide.

Inside the Nuxeo Repository security is always checked when accessing a document.

The Nuxeo security model includes :

Inside the repository each single document can have an ACP. By default security descriptors are inherited from their parent, but inheritance can be blocked when needed.

The security engine also lets you contribute custom policy services so that security management can include business rules.

The security model and policy service are described in detail later in this document.

When an event occurs inside the repository (document creation, document modification, etc...), an event is sent to the event service that dispatches the notification to its listeners. Listeners can perform any number of actions when receiving an event, which may include modifying the document on the fly.

As an example, part of the dublincore management logic is implemented as a CoreEvent listener: whenever a document is created or modified, the "creation date", "modification date", "author" and "contributors" fields are automatically updated by a CoreEvent Listener.

The Core Events system is explained in more detail later in this document (see ??? and ???) and in the Learning Nuxeo EP5 guide.

The Repository supports a Query API to extract Documents using SQL like queries.

NXQL (the associated Query Language) is presented later in this document (see ???).

The documents in the repository can be versioned.

Nuxeo Core provides:

The versioning system is explained in details later in this document (see ???).

Nuxeo Core exposes a repository API on top of Jackrabbit JSR170 repository.

Nuxeo repository is implemented using an SPI and extension point model: this basically means that a non JCR based repository plugin can be contributed. In fact, we have already started a native SQL repository implementation (that is not yet finished because we have no direct requirement for such a repository).

Nuxeo core can server several repository: it provides a extension point to declare an additional repository: this means a single web application can use several document repositories.

Inside Nuxeo EP and especially inside the Core API the main data object is a Document.

Inside Nuxeo Core API, the object artifact used to represent a Document is called a DocumentModel.

The DocumentModel artifact encapsulates several useful features:

A DocumentModel can be located inside the repository using a DocumentRef. DocumentRef can be an IdRef (UUID in the case of the JCR Repository Implementation) or PathRef (absolute path).

DocumentModels also hold information about the Type of the Document and a set of flags to define some useful characteristics of the Document:

A Proxy is a DocumentModel that points to a another one: very much like a symbolic link between 2 files.

Proxies are used when the same document must be accessible from several locations (paths) in the repository. This is typically the case when doing publishing: the same document can be visible in several sections (note: 'section' here has a special meaning as defined in the Nuxeo User Guide). In order to avoid duplicating the data, we use proxies that point to same document.

A proxy can point to a checked out document (not yet associated to a version label) or to a versioned version (typical use-case of publishing).

The proxy does not store document data: all data access are forwarded to the source document. But the Proxy does holds:

TO DO

The service layer is an ECM services stack on top of the Nuxeo Repository. In a sense, the Repository itself is very much like any service of this layer, it just plays a central role.

This service layer is used for :

This service layer provides the API used by client applications (Webapp or RCP based applications) to do their work.

This means that in this layer, services don't care about UI, navigation or pageflows: they simply explore an API to achieve document oriented tasks.

Nuxeo platform provides a lot of different services, but they all fellow the same implementation pattern. This basically means that once you understand how works one service, you almost know how they all work.

As with everything in the Nuxeo Platform the services use the Nuxeo Runtime component model.

A generic service will be composed of the following packages :

Typically, the POJO module will be a Nuxeo Runtime Component that inherits from DefaultComponent, provides extension points and implements a Service Interface.

public class RelationService extends DefaultComponent 
      implements RelationManager { ...}

The deployment descriptor associated with the component will register the component, declare it as service provider and it may also declare extension points

<?xml version="1.0"?>
<component name="org.nuxeo.ecm.platform.relations.services.RelationService">
  <implementation class="org.nuxeo.ecm.platform.relations.services.RelationService" />
  <service>
    <provide interface="org.nuxeo.ecm.platform.relations.api.RelationManager" />
  </service>
  <!-- declare here extension points -->
</component>      

The facade will declare an EJB that implements the same service interface. In simple cases, the implementation simply delegates calls to the POJO component.

The facade package will also contain a contribution to the Runtime Service management to declare the service implementation.

<?xml version="1.0" encoding="UTF-8"?>
<component name="org.nuxeo.ecm.platform.relation.service.binding.contrib">
  <extension target="org.nuxeo.runtime.api.ServiceManagement" point="services">
      <documentation> Define the Relation bean as a platform service. </documentation>
      <service class="org.nuxeo.ecm.platform.relations.api.RelationManager" group="platform/relations">
        <locator>%RelationManagerBean</locator>
      </service>
    </extension>
</component>

Thanks to this declaration the POJO and the EJB Facade can now be used for providing the same interface based on a configuration of the framework and not on the client code.

This configuration is used when deploying Nuxeo components on several servers: platform configuration provides a way to define service groups and to bind them together on physical servers.

Each service provides its own API composed of a main interface and of the other interfaces and types that can be accessed.

The API package is unique for a given service, and access to a remote EJB3 based service is the same as accessing the POJO service.

From the client point of view, accessing a service is very simple and independent from service location and implementation: this means a manual JNDI call is not required. Everything that is needed is encapsulated in the Framework.getService runtime API.

RelationManager rm = Framework.getService(RelationManager.class);

The framework.getService will return the interface of the required service:

The choice of the implementation to return is left to the Nuxeo Runtime that will take the decision based on the platform configuration.

The client can explicitly ask for the POJO service via the Framework.getLocalService() API: this is typically used in the EJB Facade to delegate calls to the POJO implementation.

DocumentModel adapters are a way to adapt the DocumentModel interface (that is purely data oriented) to a more business logic oriented interface.

In the pure Service logic, adding a comment to a document would look like this:

CommentManager cm = Framework.getService(CommentManager.class);
cm.createComment(doc,"my comment");
List<DocumentModel> comments = cm.getComments(doc);

DocumentModel adapters give the possibility to have a more object oriented API:

CommentableDoc cDoc = doc.getAdapter(CommentableDoc);
cDoc.addComment("my comment");
List<DocumentModel> comments = cDoc.getComments();

The difference may seem small, but DocumentModel adapter can be very handy

DocumenModelAdapters are declared using an extension point that defines the interface provided by the adapter and the factory class. DocumentModelAdapters can be associated to a Facet of the DocumentModel.

TO DO

Nuxeo EP is designed to be scalable and thus to be deployed on many servers. It can be installed on only one server for a start, and can also easily be installed on many servers. The constant is that there is the need to have one high-end server with good performances. Then the other servers can be more lower-end.

So the numbers below are given for the one needed high-end server.

The default persistence configuration is lightweight and easy to use, but it is not made for performance.

Different backends may be set as well for Nuxeo Core repository as for all other nuxeo services that persist data. See Chapter 7, RDBMS Storage and Database Configuration for more details, here is a list of known working backends.

To set up VCS, you first need create a datasource for it. The datasource is not a standard JDBC datasource, so has different syntax, even though it contains information about JDBC connection parameters. This file is usually named $JBOSS_HOME/server/default/deploy/nuxeo.ear/datasources/default-repository-ds.xml.

<?xml version="1.0"?>
<connection-factories>
  <tx-connection-factory>
    <jndi-name>NXRepository/default</jndi-name>
    <xa-transaction/>
    <track-connection-by-tx/>
    <adapter-display-name>Nuxeo SQL Repository DataSource</adapter-display-name>
    <rar-name>nuxeo.ear#nuxeo-core-storage-sql-ra-1.5-SNAPSHOT.rar</rar-name>
    <connection-definition>org.nuxeo.ecm.core.storage.sql.Repository</connection-definition>
    <config-property name="name">default</config-property>
    <config-property name="xaDataSource" type="java.lang.String">org.postgresql.xa.PGXADataSource</config-property>
    <config-property name="property" type="java.lang.String">ServerName=localhost</config-property>
    <config-property name="property" type="java.lang.String">PortNumber/Integer=5432</config-property>
    <config-property name="property" type="java.lang.String">DatabaseName=nuxeo</config-property>
    <config-property name="property" type="java.lang.String">User=nuxeo</config-property>
    <config-property name="property" type="java.lang.String">Password=password</config-property>
    <max-pool-size>20</max-pool-size>
  </tx-connection-factory>
</connection-factories>

You will then need to specify the actual repository configuration, usually store in a file named $JBOSS_HOME/server/default/deploy/nuxeo.ear/config/default-repository-config.xml

<?xml version="1.0"?>
<component name="default-repository-config">
  <extension target="org.nuxeo.ecm.core.repository.RepositoryService" point="repository">
    <repository name="default"
      factory="org.nuxeo.ecm.core.storage.sql.coremodel.SQLRepositoryFactory">
      <repository name="default">
        <indexing>
          <!-- example configuration for H2
          <fulltext analyzer="org.apache.lucene.analysis.fr.FrenchAnalyzer"/>
          -->
          <!-- example configuration for PostgreSQL
          <fulltext analyzer="french"/>
          -->
          <!-- example configuration for Microsoft SQL Server
          <fulltext catalog="nuxeo" analyzer="french"/>
          -->
        </indexing>
        <!-- uncomment this to enable clustering
             delay is in milliseconds
               default delay is 0 (no delay before processing invalidations)
        <clustering enabled="true" delay="1000" />
        -->
      </repository>
    </repository>
  </extension>
</component>

First you have to specify a datasource in $JBOSS_HOME/server/default/deploy/nuxeo.ear/datasources/default-repository-ds.xml.

<?xml version="1.0"?>
<!DOCTYPE connection-factories PUBLIC
  "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
  "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd">
<connection-factories>
  <mbean code="org.nuxeo.ecm.core.repository.JBossRepository"
         name="nx:type=repository,name=default">
    <constructor>
      <arg type="java.lang.String" value="default"/>
    </constructor>
  </mbean>
  <tx-connection-factory>
    <jndi-name>NXRepository/default</jndi-name>
    <adapter-display-name>NX Repository Adapter</adapter-display-name>
    <rar-name>nuxeo.ear#nuxeo-core-jca-${project.version}.rar</rar-name>
    <connection-definition>org.nuxeo.ecm.core.model.Repository</connection-definition>
    <xa-transaction/>
    <!-- Configuration properties. -->
    <config-property name="name">default</config-property>
  </tx-connection-factory>
</connection-factories>

Then edit $JBOSS_HOME/server/default/deploy/nuxeo.ear/config/default-repository-config.xml.

<?xml version="1.0"?>
<component name="default-repository-config">
  <documentation>
    Defines the default JackRabbit repository used for development and testing.
  </documentation>
  <extension target="org.nuxeo.ecm.core.repository.RepositoryService"
    point="repository">
    <documentation>
      Declare a JackRabbit repository to be used for development and tests. The
      extension content is the Jackrabbit XML configuration of the repository.
    </documentation>
    <repository name="default"
      factory="org.nuxeo.ecm.core.repository.jcr.JCRRepositoryFactory"
      securityManager="org.nuxeo.ecm.core.repository.jcr.JCRSecurityManager"
      forceReloadTypes="false">
      <Repository>
        <!--
          virtual file system where the repository stores global state
          (e.g. registered namespaces, custom node types, etc.)
        -->
        <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
          <param name="path" value="${rep.home}/repository" />
        </FileSystem>
        <!--
          security configuration
        -->
        <Security appName="Jackrabbit">
          <!--
            access manager:
            class: FQN of class implementing the AccessManager interface
          -->
          <AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager">
            <!-- <param name="config" value="${rep.home}/access.xml"/> -->
          </AccessManager>
          <LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule">
            <!-- anonymous user name ('anonymous' is the default value) -->
            <param name="anonymousId" value="anonymous" />
            <!--
              default user name to be used instead of the anonymous user
              when no login credentials are provided (unset by default)
            -->
            <!-- <param name="defaultUserId" value="superuser"/> -->
          </LoginModule>
        </Security>

        <!--
          location of workspaces root directory and name of default workspace
        -->
        <Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default" />
        <!--
          workspace configuration template:
          used to create the initial workspace if there's no workspace yet
        -->
        <Workspace name="${wsp.name}">
          <!--
            virtual file system of the workspace:
            class: FQN of class implementing the FileSystem interface
          -->
          <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
            <param name="path" value="${wsp.home}" />
          </FileSystem>

          <!--
            persistence manager of the workspace:
            class: FQN of class implementing the PersistenceManager interface
          -->
          <PersistenceManager class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager">
          </PersistenceManager>

          <!--
            Search index and the file system it uses.
            class: FQN of class implementing the QueryHandler interface
          -->
          <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
            <param name="path" value="${wsp.home}/index" />
          </SearchIndex>
        </Workspace>

        <!--
          Configures the versioning
        -->
        <Versioning rootPath="${rep.home}/version">
          <!--
            Configures the filesystem to use for versioning for the respective
            persistence manager
          -->
          <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
            <param name="path" value="${rep.home}/version" />
          </FileSystem>

          <!--
            Configures the persistence manager to be used for persisting version state.
            Please note that the current versioning implementation is based on
            a 'normal' persistence manager, but this could change in future
            implementations.
          -->
          <PersistenceManager class="org.apache.jackrabbit.core.state.obj.ObjectPersistenceManager">
          </PersistenceManager>
        </Versioning>

        <!--
          Search index for content that is shared repository wide
          (/jcr:system tree, contains mainly versions)
        -->
        <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
          <param name="path" value="${rep.home}/repository/index" />
        </SearchIndex>
      </Repository>
    </repository>
  </extension>
</component>

          

Change the two PersistenceManager sections defining various database connection settings.

Refer to the Jackrabbit documentation for more information, and to the Jackrabbit Javadoc for details about configuring the PersistenceManager.

In particular, decide if you want the binary blobs stored inside the database or in the filesystem (change externalBLOBs to true if you want them outside the database, in the filesystem).

Using externalized Blobs can provide a performance improvement in particular if you need to store a lot of big files. Depending on the RDBMS used, there may also be a max size limit for blob if you store them in the RDBMS (for PostgeSQL 8.2 blobs are limited to 1 GB).

Here are some examples:

        <!-- Workspaces configuration. Nuxeo only uses the default workspace. -->
        (...)
          <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
            <param name="driver" value="org.postgresql.Driver"/>
            <param name="url" value="jdbc:postgresql://localhost/nuxeo"/>
            <param name="user" value="postgres"/>
            <param name="password" value="password"/>
            <param name="schema" value="postgresql"/>
            <param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
            <param name="externalBLOBs" value="false"/>
          </PersistenceManager>
        (...)
        <!-- Versioning configuration. -->
          (...)
          <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
            <param name="driver" value="org.postgresql.Driver"/>
            <param name="url" value="jdbc:postgresql://localhost/nuxeo"/>
            <param name="user" value="postgres"/>
            <param name="password" value="password"/>
            <param name="schema" value="postgresql"/>
            <param name="schemaObjectPrefix" value="jcr_ver_"/>
            <param name="externalBLOBs" value="false"/>
          </PersistenceManager>

          

        <!-- Workspaces configuration. Nuxeo only uses the default workspace. -->
        (...)
          <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager">
            <param name="driver" value="com.mysql.jdbc.Driver"/>
            <param name="url" value="jdbc:mysql://localhost/nuxeo"/>
            <param name="user" value="mysql"/>
            <param name="password" value="password"/>
            <param name="schema" value="mysql"/>
            <param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
            <param name="externalBLOBs" value="true"/>
          </PersistenceManager>
        (...)
        <!-- Versioning configuration. -->
          (...)
          <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager">
            <param name="driver" value="com.mysql.jdbc.Driver"/>
            <param name="url" value="jdbc:mysql://localhost/nuxeo"/>
            <param name="user" value="mysql"/>
            <param name="password" value="password"/>
            <param name="schema" value="mysql"/>
            <param name="schemaObjectPrefix" value="jcr_ver_"/>
            <param name="externalBLOBs" value="true"/>
          </PersistenceManager>

          

Note: "schemaObjectPrefix" must have different values in workspace & versioning configuration

For JackRabbit, there are some persistence manager specific to each RDBMS :

Create the database in the database server, enable IP connection, setup permissions and test the connection.

You can now start JBoss AS and verify that your new repository is used!

Each service can use a dedicated datasource to define the database connection. However, to simplify configuration, all datasources are JNDI NamingAlias pointing to a single datasource (NuxeoDS). If you want to change the default database, you can simply do the following:

The default configuration has a commented out PostgresSQL configuration.

To use a dedicated datasource for a service, you need to modify its configuration file. If you would like to store audit logs in PostgreSQL using its own datasource, remove the NamingAlias in nxaudit-logs-ds.xml and replace it with the datasource configuration example:

<?xml version="1.0"?>
<datasources>
  <local-tx-datasource>
    <jndi-name>nxaudit-logs</jndi-name>
    <connection-url>jdbc:postgresql://localhost/logs</connection-url>
    <driver-class>org.postgresql.Driver</driver-class>
    <user-name>username</user-name>
    <password>password</password>
  </local-tx-datasource>
</datasources>
        

We recommend to enable XA transactions if your database server support it (for PostgreSQL, you have to use 8.x versions). The following datasource definition example enables XA transaction for the Audit Service using PostgreSQL.

<?xml version="1.0"?>
<datasources>
   <xa-datasource>
     <jndi-name>nxaudit-logs</jndi-name>
     <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
     <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
     <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
     <xa-datasource-property name="DatabaseName">logs</xa-datasource-property>
     <xa-datasource-property name="User">postgres</xa-datasource-property>
     <xa-datasource-property name="Password">password</xa-datasource-property>
     <track-connection-by-tx/>
   </xa-datasource>
</datasources>
        

See Datasources Configuration on the JBoss wiki for more examples of datasources.

This method works for most services:

<connection-url>
  jdbc:mysql://localhost/nuxeo?relaxAutoCommit=true
</connection-url>
        

<connection-url>
  jdbc:mysql://localhost/nuxeo?relaxAutoCommit=true&amp;emulateLocators=true
</connection-url>
        

The Relation Service uses a datasource to define the data storage. However modifying the datasource is not enough, you also have to tell to the Jena engine which database dialect is used, as it doesn't auto-detect it.

To do that, edit the sql.properties file in $JBOSS_HOME/server/default/deploy/nuxeo.ear/config/ and change the definition of the org.nuxeo.ecm.sql.jena.databaseType property. The possible values are:

In the same file, the property org.nuxeo.ecm.sql.jena.databaseTransactionEnabled is set to true by default.

Please refer to the Jena Site for more information about database support.

The value of the above properties are used as variables by the extension point defining the Jena configuration, so that they only have to be changed in one place.

The Tag Service uses a datasource file to define the data storage. The service uses joins with tables located in default repository DB instance, so in order to work it is a must to be configured on the same database instance as the default repository. Short line, the nxtags-ds.xml file has to be compliant with whatever is set in the default-repository-ds.xml file.

Note that this section is obsolete in Nuxeo 5.2, and should not be used anymore.

The Compass plugin is configured using a datasource, but at the time of this writing it still needs some additional configuration in a file embedded in its Jar. You should go to $JBOSS_HOME/server/default/deploy/nuxeo.ear/system/ and inside the directory nuxeo-platform-search-compass-plugin-5.1-SNAPSHOT.jar (the version number may be different) then edit the file compass.cfg.xml. You will find a section like:

<connection>
  <jdbc managed="true"
    dialectClass="org.apache.lucene.store.jdbc.dialect.HSQLDialect"
    deleteMarkDeletedDelta="3600000">
    <dataSourceProvider>
      <jndi lookup="java:/nxsearch-compass" />
    </dataSourceProvider>
  </jdbc>
</connection>
      

The dialectClass has to be changed according to your datasource configuration. The possible values end with MySQLDialect, PostgreSQLDialect , etc. They are documented in the Compass documention about SQL dialects .

Create a repository definition as a contribution to the extension point org.nuxeo.ecm.core.repository.RepositoryService (for example: MyRepo-repositoy-config.xml) in $JBOSS_HOME/server/default/deploy/nuxeo.ear/config/.

You can take example on the default repository definition $JBOSS_HOME/server/default/deploy/nuxeo.ear/config/default-repository-config.xml.

You have to properly configure the following aspects:

Refer to the Jackrabbit documentation for more information, and to the Jackrabbit Javadoc for details about configuring the BundleDbPersistenceManager.

<?xml version="1.0"?>
<component name="org.nuxeo.project.sample.repository.MyRepo">
  <extension target="org.nuxeo.ecm.core.repository.RepositoryService" point="repository">
    <repository name="MyRepo"
                factory="org.nuxeo.ecm.core.repository.jcr.JCRRepositoryFactory"
                securityManager="org.nuxeo.ecm.core.repository.jcr.JCRSecurityManager"
                forceReloadTypes="false">
      <Repository>
        <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
          <param name="path" value="${rep.home}/repository"/>
        </FileSystem>
        <Security appName="Jackrabbit">
          <AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager">
        </AccessManager>
          <LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule">
            <param name="anonymousId" value="anonymous"/>
          </LoginModule>
        </Security>

        <!-- Workspaces configuration. Nuxeo only uses the default workspace. -->
        <Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default"/>
        <Workspace name="${wsp.name}">
          <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
            <param name="path" value="${wsp.home}"/>
          </FileSystem>
          <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
            <param name="driver" value="org.postgresql.Driver"/>
            <param name="url" value="jdbc:postgresql://localhost/nuxeo"/>
            <param name="user" value="postgres"/>
            <param name="password" value="password"/>
            <param name="schema" value="postgresql"/>
            <param name="schemaObjectPrefix" value="jcr_${wsp.name}_"/>
            <param name="externalBLOBs" value="false"/>
          </PersistenceManager>
          <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
            <param name="path" value="${wsp.home}/index"/>
          </SearchIndex>
        </Workspace>

        <!-- Versioning configuration. -->
        <Versioning rootPath="${rep.home}/version">
          <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
            <param name="path" value="${rep.home}/version"/>
          </FileSystem>
          <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
            <param name="driver" value="org.postgresql.Driver"/>
            <param name="url" value="jdbc:postgresql://localhost/nuxeo"/>
            <param name="user" value="postgres"/>
            <param name="password" value="password"/>
            <param name="schema" value="postgresql"/>
            <param name="schemaObjectPrefix" value="jcr_ver_"/>
            <param name="externalBLOBs" value="false"/>
          </PersistenceManager>
        </Versioning>

        <!-- Index for repository-wide information, mainly versions. -->
        <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
          <param name="path" value="${rep.home}/repository/index"/>
        </SearchIndex>
      </Repository>
    </repository>
  </extension>
</component>

TODO: this should be moved to a different section as it doesn't pertain to the SQL configuration itself.

You have now replaced the default repository (demo) with your newly defined one (MyRepo). To actually use it, create or edit the file MyPlatform-Layout-config.xml in $JBOSS_HOME/server/default/deploy/nuxeo.ear/config/ and configure the parameters as shown in the following example.

<?xml version="1.0"?>
<component name="MyPlatformLayout">

  <require>org.nuxeo.ecm.platform.api.DefaultPlatform</require>

  <extension target="org.nuxeo.ecm.platform.util.LocationManagerService" point="location">
    <locationManagerPlugin> <!-- This disable the default (demo) repository -->
      <locationEnabled>false</locationEnabled>
      <locationName>demo</locationName>
    </locationManagerPlugin>
    <locationManagerPlugin> <!-- This enable your new repository -->
      <locationEnabled>true</locationEnabled>
      <locationName>MyRepo</locationName> <!-- Use the name of your repository -->
    </locationManagerPlugin>
  </extension>

 <extension target="org.nuxeo.ecm.core.api.repository.RepositoryManager"
    point="repositories">
    <documentation>The default repository</documentation>
    <repository name="MyRepo" label="My Repository"/>
  </extension>

  <extension target="org.nuxeo.runtime.api.ServiceManagement" point="services">
      <service class="org.nuxeo.ecm.core.api.CoreSession" name="MyRepo" group="core">
          <locator>%DocumentManagerBean</locator>
      </service>
  </extension>

</component>
      

This sample configuration creates a new repository in the core Group that will be assigned to the default server. If you want to have it located on an other server you can use:

<extension target="org.nuxeo.runtime.api.ServiceManagement" point="servers">
  <!-- define new locator for group MyGroup -->
  <server class="org.nuxeo.runtime.api.JBossServiceLocator">
    <group>MyGroup</group>
    <property name="java.naming.factory.initial">org.jnp.interfaces.NamingContextFactory</property>
    <property name="java.naming.provider.url">jnp://MyServer:1099</property>
    <property name="java.naming.factory.url.pkgs">org.jboss.naming:org.jnp.interfaces</property>
  </server>

  <!-- bind MyRepo to MyGroup -->
  <extension target="org.nuxeo.runtime.api.ServiceManagement" point="services">
    <service class="org.nuxeo.ecm.core.api.CoreSession" name="MyRepo" group="MyGroup">
      <locator>%DocumentManagerBean</locator>
    </service>
  </extension>

</extension>
      

This table sums up how data migration are handled : YES if the operation is supported, NO if not and into brackets, reference to the relative procedure.

These use cases were tested on JCR Storage with PostgreSQL. for data persistence.

All manipulations on document structure are supported without changing any configuration file.

Since version 2.3, OpenOffice can be started in headless mode. This means that under linux, you non longer need to run a Xvfb.

Use the oooctl control script or, depending on your system and installation method, start OOo running :

Nuxeo has developed some tools to ease the settings, they are available at the Nuxeo svn tools ooo section as extensions to install in OpenOffice. This can be done thru the GUI via the menu "Tools>Extensions Manager>Add..." or by opening the wanted extension with OpenOffice. To do it from a command line, run:

/path/to/openoffice/program/unopkg add extension.oxt

Starting with 5.2-M4, Nuxeo includes a Daemon to start and manage OpenOffice server.

This daemon is based on the OpenOffice Server Daemon project

OOo Daemon provides :

Configuration is done via an xml extension point. Defaut config can be editer in file located in nuxeo.ear/config/ooo-config.xml.

<?xml version="1.0"?>
<component name="org.nuxeo.ecm.platform.convert.oooDaemon.config.default">

  <extension target="org.nuxeo.ecm.platform.convert.oooserver.OOoDaemonManagerComponent"
    point="oooServerConfig">

  <OOoServer>
    <!-- enable Nuxeo Daemon to manage OOo server instances : default is true -->
    <enableDaemon>true</enableDaemon>
    <!-- define OOo server listen IP : used even if daemon is disabled -->
    <oooListenIP>127.0.0.1</oooListenIP>
    <!-- define OOo server listen port : used even if daemon is disabled -->
    <oooListenPort>8100</oooListenPort>
    <!-- define Daemon listen port : used only if daemon is enabled -->
    <oooDaemonListenPort>8101</oooDaemonListenPort>
    <!-- define number of OOo worker process : used only if daemon is enabled -->
    <oooWorkers>1</oooWorkers>

    <!-- define OOo installation path : used only if daemon is enabled -->
    <!-- if not defined Nuxeo will try to find the path automatically -->
    <!--<oooInstallationPath>/usr/lib/openoffice/program</oooInstallationPath>-->

    <!-- define jpipe library path : used only for OOo 3 -->
    <!--<jpipeLibPath>/opt/openoffice.org/ure/lib</jpipeLibPath>-->

    <!-- define number of time a worker process can be used before being recycled: used only if daemon is enabled -->
    <oooWorkersRecycleInterval>10</oooWorkersRecycleInterval>

    <!-- define is Daemon is started at server startup : used only if daemon is enabled -->
    <autoStart>false</autoStart>

  </OOoServer>

  </extension>

</component>

In most cases, you should not have to define the location of your OpenOffice installation as the Daemon will try to find it in the standard installation path.

If you want to use OpenOffice 3.x, you have to specify the jpipeLibPath in order to enable jpipe that is used by the Daemon to communicate with OpenOffice workers.

The last binary release and installation instructions for your OS can be found here.

The simplest way to get it working with Nuxeo is to get the ImageMagick binaries in the PATH of the user launching Nuxeo.

For the image tiling feature, if you can't add the ImageMagick binaries to your path or if you want to specify the full path of the ImageMagick binaries, you will have to override the default contributions. First of all, you need to specify the full path to the ImageMagick binaries for the image tiling by creating a config file in nuxeo.ear/config.

pictures-tiles-config.xml

<?xml version="1.0"?>
<component name="com.myproject.tiles.config">
  <extension target="org.nuxeo.ecm.platform.pictures.tiles.service.PictureTilingComponent"
    point="environment">

  <environment>
    <parameters>
      <parameter name="IMConvert">/path/to/imagemagick/convert</parameter>
      <parameter name="IMIdentify">/path/to/imagemagick/identify</parameter>
      <parameter name="IMStream">/path/to/imagemagick/stream</parameter>
    </parameters>
  </environment>

</component>

Then, you have to override the pdftoimage command to point to the ImageMagick convert binary.

commandline-pdf2image-config.xml

<?xml version="1.0"?>
<component name="com.myproject.pdftoimage.config">

  <extension target="org.nuxeo.ecm.platform.commandline.executor.service.CommandLineExecutorComponent"
    point="command">

    <command name="pdftoimage" enabled="true">
      <commandLine>/path/to/imagemagick/convert</commandLine>
      <parameterString>#{sourceFilePath} #{targetFilePath}</parameterString>
      <installationDirective>You need to install ImageMagick.</installationDirective>
    </command>

  </extension>

</component>

The installation instructions for UFRaw can be found here. See below for specific OS installation.

Don't forget to check that the binaries are in the PATH of the user launching Nuxeo.

The latest version of Ghostscript can be found here. See below for specific OS installation.

Don't forget to check that the binaries are in the PATH of the user launching Nuxeo.

The simplest way to use it with Nuxeo is to have the pdftohtml binary in the PATH of the user launching Nuxeo.

If for any reason you can't do this, you have to override the default contribution by creating a commandline-pdf2html-config.xml file for example, and put it under nuxeo.ear/config:

<?xml version="1.0"?>
<component name="com.myproject.pdftohtml.config">

  <extension target="org.nuxeo.ecm.platform.commandline.executor.service.CommandLineExecutorComponent"
    point="command">

    <command name="pdftohtml" enabled="true">
      <commandLine>/path/to/pdftohtml</commandLine>
      <parameterString> -c -noframes #{inFilePath} #{outDirPath}/index.html</parameterString>
      <installationDirective>You need to install pdftohtml</installationDirective>
    </command>

  </extension>

</component>

For this configuration, you will need to load and enable mod_proxy and mod_proxy_http modules.

ProxyPass /nuxeo/ http://Nuxeo5ServerInternalIp:8080/nuxeo/
ProxyPassReverse /nuxeo/ http://Nuxeo5ServerInternalIp:8080/nuxeo/

You can also use rewrite rules to achieve the same result:

ProxyVia On
ProxyRequests Off
RewriteEngine On
RewriteRule /nuxeo(.*) http://Nuxeo5ServerInternalIp:8080/nuxeo$1 [P,L]

This configuration will allow you to access the Nuxeo EP webapp via http://ApacheServer/nuxeo/.

The Nuxeo webapp will generate the URLs after reading the http header x-forwarded-host.

Unfortunately, this header does not specify the protocol used, so if your Apache is responding to HTTPS, you will need to send Nuxeo EP a specific header to indicate the base URL that the webapp must use when generating links.

RequestHeader append nuxeo-virtual-host "https://myDomainName/"

This will require you to load and activate mod_headers module.

And if you have "client denied by server configuration" error, you must check the access control directives of mod_proxy:

<Proxy *>
  Order Deny,Allow
  Deny from all
  Allow from 192.168
</Proxy> 

You need the same configuration from the first section. It is advised to first get it to work before proxying exclusively a Webengine site.

A site request queries both from its own url (/nuxeo/site/mysite) but also get static resources from the root (/nuxeo/nxthemes ...). A rewrite configuration for mysite would look like:

RewriteRule ^/nuxeo$   /nuxeo/  [P,L]
RewriteRule ^/mysite$   /mysite/  [P,L]

RewriteCond %{REQUEST_URI}  ^/mysite/skin/mysite/.*
RewriteRule ^/mysite/skin/mysite/(.*) http://127.0.0.1:8080/nuxeo/site/skin/mysite/$1 [P,L]

RewriteCond %{REQUEST_URI}  ^/mysite/skin/.*
RewriteRule ^/mysite/skin/(.*) http://127.0.0.1:8080/nuxeo/site/skin/mysite/$1 [P,L]

RewriteCond %{REQUEST_URI}  ^/mysite/nxthemes-(lib|css)/.*
RewriteRule ^/mysite/(.*) http://127.0.0.1:8080/nuxeo/$1 [P,L]


RewriteCond %{REQUEST_URI}  ^/mysite/nxthemes-webwidgets/.*
RewriteRule ^/mysite/(.*) http://127.0.0.1:8080/nuxeo/site/$1 [P,L]

RewriteRule ^/mysite/(.*) http://127.0.0.1:8080/nuxeo/site/mysite/$1 [P,L]

Webengine also needs to know the base of the site, in this case, an empty string instead of /nuxeo/site. This information is passed using the mod_headers:

RequestHeader append nuxeo-webengine-base-path ""

You can also fetch the static resources from a different path. To do so add a properties to the nuxeo.properties file

org.nuxeo.ecm.webengine.skinPathPrefix=/skin/

mod_jk allows you to communicate between Apache and Tomcat via the ajp1.3 protocol.

JkWorkersFile /etc/apache2/jk/workers.properties
JkLogFile     /var/log/mod_jk.log
JkLogLevel    info
JkMount /nuxeo ajp13
JkMount /nuxeo/* ajp13    

The workers.properties file will contain the list of Nuxeo EP Tomcat servers. The AJP13 tomcat listener should be enabled by default on port 8009.

worker.list=ajp13
worker.ajp13.port=8009
worker.ajp13.host=Nuxeo5ServerInternalIp
worker.ajp13.type=ajp13
worker.ajp13.socket_keepalive=1
worker.ajp13.connection_pool_size=50    

Once again, if you use HTTPS, you will need to set the Nuxeo-specific header to tell the webapp how to generate URLs:

RequestHeader append nuxeo-virtual-host "https://myDomainName/"

This will require you to load and activate the mod_header module.

The Simple cache filter is deprecated, we recommand using the filterConfig extension point of RequestControllerService.

 <extension target="org.nuxeo.ecm.platform.web.common.requestcontroller.service.RequestControllerService"
  point="filterConfig">

   <filterConfig name="filterName" transactional="true" synchonize="true"
     cached="true" private="true" cachetime="3600">
   <pattern>/nuxeo/urlPattern/.*</pattern>
   </filterConfig>
 </extension>
      

<extension target="web#FILTER">
  <filter-mapping>
    <filter-name>simpleCacheFilter</filter-name>
    <url-pattern>/MyURLsToCache/*</url-pattern>
  </filter-mapping>
</extension>

Download and compile pg_standby .

For example, from a tgz postgresql 8.2.6 installation, do :

cd postgresql-8.2.6/contrib
mkdir pg_standby
cd pg_standby
wget https://projects.commandprompt.com/public/pgsql/repo/trunk/pgsql/contrib/pg_standby/Makefile
wget https://projects.commandprompt.com/public/pgsql/repo/trunk/pgsql/contrib/pg_standby/pg_standby.c
cd ../..
./configure
cd -
make
make install

This builds a pg_standby binary that is used on standby server. Alternative scripts may be written to replace it.

Download the Nuxeo replication tools on each server: http://hg.nuxeo.org/tools/nuxeo-postgresql-replication .

From the nuxeo-postgresql-replication directory, run "sudo make install" to install or upgrade nx-failover tool.

If you want to package the tool, run "make pkg" in order to generate an archive and quickly distribute it.

Data from all datasources and data from the repository need to be synchronized between two Nuxeo instances. Except all that is stored depending on the datasources and the repository configuration, there are still some indexes to synchronize that are in:

$JBOSS/server/default/data/NXRuntime/

Be careful that this file that may contain server-specific data (i.e. its IP address or DNS alias) :

$JBOSS/server/default/data/NXRuntime/repos/default/default.xml

SSH between servers must be enabled and host keys verified (for postgres and jboss users). PostgreSQL process will have to su jboss user on both servers (master and slave).

Here are the commands to execute at initialization :

In case of master server failure (or to switch servers for maintenance or tests purpose), do:

Download the Nuxeo replication tools on each server: http://svn.nuxeo.org/nuxeo/tools/replication/trunk .

Copy and parameterize init-var.sh.sample to init-var.sh. This documentation assume you have set postgresql-8.2 and nuxeo-server services; if not, the scripts can do it (see "make_symlinks" in "init-nuxeo.sh" and "init-system.sh").

SSH between servers must be enabled and host keys verified (for postgres and jboss users). PostgreSQL process will have to su jboss user on both servers (primary and standby).

Here are the commands to execute at initialization :

In case of primary server failure (or to switch servers for maintenance or tests purpose), do:

The configuration is not specific to Nuxeo. JBoss documentation is available here

A JMX server allows communication between different MBean. From Java 5, a JMX server is included in the JVM. JBoss creates its own JMX server. To set JBoss so it uses the same JMX server than the JVM and to be able to connect to it, you need modify the command line to launch JBoss

For a linux distribution you need to add to run.conf:

# Enable the jconsole agent locally
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
# Tell JBossAS to use the platform MBean server
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
# Make the platform MBean server able to work with JBossAS MBeans
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"

For Windows, you need to add to run.bat:

%JAVA_OPTS% -Dcom.sun.management.jmxremote
set JAVA_OPTS=%JAVA_OPTS% -Djboss.platform.mbeanserver
set JAVA_OPTS=%JAVA_OPTS% -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl

Because of a bug in jboss-cache, it is necessary to replace jboss-cache by a patched version. You need to replace:

$JBOSS/server/default/deploy/nuxeo.ear/lib/jboss-cache-jdk50-1.4.0.SP1.jar

by the version available here

To configure for Nuxeo 5.2.0, you first need to follow the configuration for 5.3.0 ( Section 21.1.1, “Configuration from Nuxeo 5.3.0”). You also need to modify the file $JBOSS/server/default/deploy/nuxeo.ear/config/nuxeo.properties, set the value:

org.nuxeo.runtime.management.exist=true

To use a version before the 5.2.0, you need to follow the configuration for 5.2.0 ( Section 21.1.2, “Configuration for Nuxeo 5.2.0” ). You also need to add the management jar to Nuxeo. Download the jar and put it in the folder $JBoss/server/default/deploy/nuxeo.ear/plugins.

Command options are defined by a name and optionally a shortcut (a short name). When referring to an option using its name you should prefix it by two hyphens '--'. When using short names you should only use one hyphen as a prefix. For example if you have an option named "host" and using a short name of "h" the following commands are equivalent:

$ ./nxshell.sh interactive -h localhost

$ ./nxshell.sh interactive --host localhost

Options may take values or may be used as flags turning on / off a specific option by their simple presence.

When using long names you should specify the option values immediately after the option. However when using short names you can group options together. Let say for example we have a command that support 4 options: a, v, i, o. a and v are flag options and both i and o takes an argument as value. In this case the you can group options like the following:

command -avi in_file -o out_file

or

command -avio in_file out_file

or anyhow you want. You should keep in mind that when grouping options that take arguments, these arguments will be assigned to each of this options in the order they were specified on the command line.

There is the list of all built-in commands of nuxeo shell.

Notes:

$ ./nxshell.sh interactive

$ ./nxshell.sh help ls

log4j:WARN No appenders could be found for logger (org.nuxeo.ecm.shell.commands.InteractiveCommand).
log4j:WARN Please initialize the log4j system properly.

script --file <path_to_your_script> <args>

useradd joe

useradd --file users.csv

groupmod --user joe company-service1

groupmod --set --user madarche company-service1

groupmod --file users_for_group.csv company-service1

groupmod --file users_for_group.csv company-service1

select * from Document where ...

Be sure on what precise IP address and what precise port the server is listening to. To find out, use the netstat command on the server host. The example below shows that, on the same host, there are 2 servers listening on the 62474 port but on different IP addresses. You should always use as arguments to the nuxeo shell the exact IP address and port you find out.

$ sudo netstat -ntlap | grep 62474
tcp        0      0 ::ffff:192.0.0.11:62474     :::*                        LISTEN      3623/java
tcp        0      0 ::ffff:192.0.0.10:62474     :::*                        LISTEN      1346/java      

Alternatively you can use the lsof command.

$ sudo lsof -i :62474
COMMAND   PID       USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
java     3623      jboss  266u  IPv6 0x5d69a70      0t0  TCP [::192.0.0.11]:62474 (LISTEN)
java     1346      jboss  266u  IPv6 0x5d7af30      0t0  TCP [::192.0.0.10]:62474 (LISTEN)      

Be sure to be connected on the right server. To do so, issue a view command. This will display information on the current context:

192.0.0.10> view
--------------------------------------------------------------------
UID: 2a13db70-f133-473c-9a90-6838d01610aa
Path: /
Type: Root
--------------------------------------------------------------------
Title: 2a13db70-f133-473c-9a90-6838d01610aa
Author: null
Created: null
Last Modified: null
--------------------------------------------------------------------
Description: 2a13db70-f133-473c-9a90-6838d01610aa
--------------------------------------------------------------------      

When working with multi-machine installation, connect the Nuxeo Shell on the server running Nuxeo Core (i.e. the stateful server on a bi-machine configuration).

This is how to register the new commands:

<?xml version="1.0"?>
<component name="com.company.nuxeo.shellcommands" version="1.0">

  <documentation>
    Extra Nuxeo Shell commands shown as examples for the Nuxeo Book.
  </documentation>

  <extension target="org.nuxeo.ecm.shell.CommandLineService" point="commands">

    <command name="purgeobsoletedocs" class="com.company.nuxeo.shellcommands.ObsoleteDocsPurgeCommand">
      <description>
        Purge obsolete documents considering based on predefined hard-coded logic.
      </description>
      <help>Purge obsolete documents</help>
    </command>

    <command name="addapplicants" class="com.company.nuxeo.shellcommands.ApplicantsAdderCommand">
      <description>
        Adds applicants by creating the right folders with the right permissions.
      </description>
      <params>
        <param index="0" type="path" />
      </params>
      <help>Adds applicants</help>
    </command>

  </extension>

</component>
      

This is how to write a Java class for a new command:

public class ApplicantsAdderCommand extends AbstractCommand {

    public static final String COMMAND_NAME = "addApplicants";

    public void run(CommandLine cmdLine) throws Exception {
        String[] elements = cmdLine.getParameters();
        // parse command line
        if (elements.length != 1) {
            log.error("Usage: " + COMMAND_NAME + " file");
            return;
        }
        File file = new File(elements[0]);

        addApplicants([...]);
    }

    void addApplicants([...]) {
    }

}
      

Finally the pom.xml file for the plugin to the Nuxeo shell needs to at least contain the following dependency to be able to build extend the AbstractCommand class. Building the plugin will generate a XXX.jar file. Note that you should of course replace the version given as an example with the version suited for your need.

<dependencies>

  [...]

  <dependency>
    <groupId>org.nuxeo.ecm.platform</groupId>
    <artifactId>nuxeo-shell-commands-base</artifactId>
    <version>5.1.7-SNAPSHOT</version>
  </dependency>

  [...]

</dependencies>
      

The next time the nuxeo shell is restarted your new commands will be available.

Nuxeo distribution 5.2 ZIP archive

hg clone http://hg.nuxeo.org/nuxeo/nuxeo-distribution#5.2

With Ant: "ant distrib [-Ddistrib=PROFILE,BACKEND]".

With Maven: "mvn clean install package -PPROFILE -Dmaven.test.skip=true".