The CDOServerApplication is configured with the <code>cdo-server.xml</code> file. It must be located in the '''folder''' that you declare through the system property <code>net4j.config</code>.

The CDOServerApplication is configured with the <code>cdo-server.xml</code> file. It must be located in the '''folder''' that you declare through the system property <code>net4j.config</code>.

−

Checkout this example from CVS and modify it for your needs: <code>[http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.emf/org.eclipse.emf.cdo/features/org.eclipse.emf.cdo.server.product-feature/rootfiles/configuration/cdo-server.xml?view=co&root=Modeling_Project org.eclipse.emf.cdo.server.product-feature/rootfiles/configuration/cdo-server.xml]</code>.

+

Checkout this example from Git and modify it for your needs: [http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.server.product/config/cdo-server.xml http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.server.product/config/cdo-server.xml].

The subsequent sections explain the used [[#Element cdoServer|XML Elements]].

The subsequent sections explain the used [[#Element cdoServer|XML Elements]].

Line 38:

Line 38:

===Element repository===

===Element repository===

−

Defines an [http://download.eclipse.org/modeling/emft/cdo/javadoc/0.8.0/org/eclipse/emf/cdo/server/IRepository.html|<code>IRepository</code>] instance. Please refer to [[CDO Server]] for details about repositories and sessions.

The <code>name</code> attribute uniquely identifies a repository in the scope of a repository configurator.

The <code>name</code> attribute uniquely identifies a repository in the scope of a repository configurator.

Line 114:

Line 114:

|}

|}

−

Also note that branching support always ''requires'' [[#Property supportingAudits|auditing support]]!

+

Also note that branching support always '''requires''' [[#Property supportingAudits|auditing support]]!

<br>

<br>

Line 120:

Line 120:

Specifies whether the repository will support the storage of instances of the Ecore (meta meta) model or not.

Specifies whether the repository will support the storage of instances of the Ecore (meta meta) model or not.

−

With the advent of the legacy mode (support for models not generated as [[Preparing EMF Models|CDO native models]]) in CDO 3.0 you can store instances of any model in CDO repositories. Whether these models have been generated for CDO or not only influences their characteristics (scalability, performance, etc.). As a consequence you can also store instances of the Ecore (meta meta) model in CDO Repositories. Since Ecore has always been registered in all package registries the legacy mode would lead to the creation of mapped tables in many types of stores, even if you never planned to store instances of Ecore.

+

With the advent of the [[CDO/Legacy Mode|legacy mode]] (support for models not generated as [[CDO/Preparing EMF Models|CDO native models]]) in CDO 3.0 you can store instances of any model in CDO repositories. Whether these models have been generated for CDO or not only influences their characteristics (scalability, performance, etc.). As a consequence you can also store instances of the Ecore (meta meta) model in CDO Repositories. Since Ecore has always been registered in all package registries the legacy mode would lead to the creation of mapped tables in many types of stores, even if you never planned to store instances of Ecore.

<br>

<br>

−

====Property supportingRevisionDeltas====

+

====Property serializeCommits====

−

''Deprecated.''

+

Specifies whether the repository will serialize commit operations by utilizing a lock or not.

+

+

Some stores, such as the LissomeStore, require commit operations to be serialized.

<br>

<br>

−

====Property verifyingRevisions====

+

====Property ensureReferentialIntegrity====

−

''Deprecated.''

+

Specifies whether the repository will detect and reject commits that would leave stale references in the object graph. Valid values: <code>false</code> (default) or <code>true</code>.

<br>

<br>

−

====Property currentLRUCapacity====

+

====Property allowInterruptRunningQueries====

−

''Deprecated.''

+

Specifies whether the repository will cancel a scheduled query job if it is alreading running. Some underlying stores (e.g. DBStore with a Derby database) might not be able to deal with this cleanly. For such stores, this parameter can be set to <code>false</code>.

<br>

<br>

−

====Property revisedLRUCapacity====

+

====Property idGenerationLocation====

−

''Deprecated.''

+

Specifies whether the repository will expect clients to generate IDs for new objects or whether it will ask the backend store to generate them. Valid values: <code>STORE</code> (default) or <code>CLIENT</code>.

The <code>type</code> attribute corresponds to the type of a store factory that is contributed via the <code>org.eclipse.emf.cdo.server.storeFactory</code> extension point. The remaining attributes depend on the specified type attribute value. The following values are possible with the shipped distribution (subject to user supplied extension):

The <code>type</code> attribute corresponds to the type of a store factory that is contributed via the <code>org.eclipse.emf.cdo.server.storeFactory</code> extension point. The remaining attributes depend on the specified type attribute value. The following values are possible with the shipped distribution (subject to user supplied extension):

−

* '''noop:''' Store that does nothing. A repository with a noop store can function properly as long as the the server is not restarted and the internal caches do not run full so that revisions get evicted and discarded. No additional attributes are recognized.

+

* '''mem:''' Store without real persistence. A repository with a mem store can function properly as long as the the server is not restarted. No additional attributes are recognized.

−

* '''db:''' Store that connects via JDBC to a relational database and manages persistent revisions and models through a built-in O/R mapper. A DB store element can contain the following nested elements:

+

* '''db:''' Store that connects via JDBC to a relational database and manages persistent revisions and models through a built-in O/R mapper, see [[CDO/DB Store]]. A DB store element can contain the following nested elements:

Specifies, if the store is a DBStore, at what interval the store will issue an SQL statement to keep the connection to the database alive.

+

<br>

+

+

====Property readerPoolCapacity====

+

Specifies, if the store is a DBStore, the maximum number of store accessors (JDBC connections) to keep in the reader pool. The default value is 15.

+

<br>

+

+

====Property writerPoolCapacity====

+

Specifies, if the store is a DBStore, the maximum number of store accessors (JDBC connections) to keep in the writer pool. The default value is 15.

<br>

<br>

Line 207:

Line 225:

====Element dbAdapter====

====Element dbAdapter====

−

Defines the [http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8.0/org/eclipse/net4j/db/IDBAdapter.html|<code>IDBAdapter</code>] instance of the store. Please refer to [[Net4j DB Framework]] for details about DB adapters and SQL dialects.

+

Defines the [http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8.0/org/eclipse/net4j/db/IDBAdapter.html <code>IDBAdapter</code>] instance of the store. Please refer to [[Net4j DB Framework]] for details about DB adapters and SQL dialects.

The <code>type</code> attribute corresponds to the name of a DB adapter factory that is contributed via the <code>org.eclipse.net4j.db.dbAdapters</code> extension point. No additional attributes are recognized.

The <code>type</code> attribute corresponds to the name of a DB adapter factory that is contributed via the <code>org.eclipse.net4j.db.dbAdapters</code> extension point. No additional attributes are recognized.

Line 215:

Line 233:

====Element dataSource====

====Element dataSource====

−

Defines the [http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html|<code>DataSource</code>] instance of the store.

+

Defines the [http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html <code>DataSource</code>] instance of the store.

The <code>class</code> attribute corresponds to the fully qualified name of the data source class. Please refer to your DB manual for details about the supported data sources and their attributes.

The <code>class</code> attribute corresponds to the fully qualified name of the data source class. Please refer to your DB manual for details about the supported data sources and their attributes.

Element cdoServer

The root element of the cdo-server.xml file. It can contain zero, one or several acceptor elements and zero, one or several repository elements.

Element acceptor

Defines an IAcceptor instance. Please refer to the Net4j documentation for details about acceptors and connectors.

The type attribute corresponds to the type of an acceptor factory that is contributed via the org.eclipse.net4j.util.factories extension point with a product group of org.eclipse.net4j.acceptors. The remaining attributes depend on the specified type attribute value. The following values are possible with the shipped distribution (subject to user supplied extension):

tcp: Acceptor for fast, new I/O based socket connections. The following additional attributes are recognized:

listenAddr: The network address the server socket shall be bound to. A value of "0.0.0.0" is the default (whole attribute can be omitted) and tells the socket to listen on all available addresses.

port: The network port the server socket shall be bound to. A value of "2036" is the default (whole attribute can be omitted).

jvm: Acceptor for JVM internal (non-socket based ) connections. Currently not supported by the Net4Configurator.

Please note that the acceptor element is likely to be moved to a separate Net4j configuration file in the future.

Element negotiator

Defines an INegotiator instance to be used by the connectors created by an acceptor (defined by the enclosing acceptor element). Please refer to the Net4j documentation for details about negotiators and the pluggable security concept that can be used for authentication and authorization.

The type attribute corresponds to the type of a negotiator factory that is contributed via the org.eclipse.net4j.util.factories extension point with a product group of org.eclipse.net4j.negotiators. The remaining attributes depend on the specified type attribute value. The following values are possible with the shipped distribution (subject to user supplied extension):

challenge: Negotiator for simple yet effective and cryptographically secure challenge/response based negotiations. The following additional attributes are recognized:

description: The absolute path to a file in the local file system that contains the credentials of the users in the form userid: password.

Element repository

The name attribute uniquely identifies a repository in the scope of a repository configurator.

The repository element can contain several property elements (see below) and must contain exactly one store element.

Property overrideUUID

Specifies a constant UUID for the repository. If omitted the repository will be created with a random UUID. The format of an override UUID is not further specified but should respect the file naming conventions of the used operating system.

Overriding the default random UUID can be useful if you have scripts that operate on the file system folder that is created on the server for each repository and named after the repository UUID.

Property supportingAudits

Specifies whether the repository will support audit views or not. Please note that a repository can only support audit views if its store supports audit views, as well:

Store Implementation

Allowed Values

Default Value

org.eclipse.emf.cdo.server.internal.db.DBStore

true/false

true, if the used mapping strategy supports audits

org.eclipse.emf.cdo.internal.server.mem.MEMStore

true/false

true

org.eclipse.emf.cdo.server.internal.hibernate.HibernateStore

false

false

org.eclipse.emf.cdo.server.internal.objectivity.ObjectivityStore

true/false

false

org.eclipse.emf.cdo.server.internal.db4o.DB4OStore

true/false

false

The shipped DB store does support audit views. Note also that it will not delete or update rows for modified objects if audits are supported. All revised state of the repository will be kept in the DB which can result in databases growing very large!

Property supportingBranches

Specifies whether the repository will support the creation and usage of branches below the always existing main branch or not. Please note that a repository can only support branches if its store supports branches, as well:

Property supportingEcore

Specifies whether the repository will support the storage of instances of the Ecore (meta meta) model or not.

With the advent of the legacy mode (support for models not generated as CDO native models) in CDO 3.0 you can store instances of any model in CDO repositories. Whether these models have been generated for CDO or not only influences their characteristics (scalability, performance, etc.). As a consequence you can also store instances of the Ecore (meta meta) model in CDO Repositories. Since Ecore has always been registered in all package registries the legacy mode would lead to the creation of mapped tables in many types of stores, even if you never planned to store instances of Ecore.

Property serializeCommits

Specifies whether the repository will serialize commit operations by utilizing a lock or not.

Some stores, such as the LissomeStore, require commit operations to be serialized.

Property ensureReferentialIntegrity

Specifies whether the repository will detect and reject commits that would leave stale references in the object graph. Valid values: false (default) or true.

Property allowInterruptRunningQueries

Specifies whether the repository will cancel a scheduled query job if it is alreading running. Some underlying stores (e.g. DBStore with a Derby database) might not be able to deal with this cleanly. For such stores, this parameter can be set to false.

Property idGenerationLocation

Specifies whether the repository will expect clients to generate IDs for new objects or whether it will ask the backend store to generate them. Valid values: STORE (default) or CLIENT.

Element store

The type attribute corresponds to the type of a store factory that is contributed via the org.eclipse.emf.cdo.server.storeFactory extension point. The remaining attributes depend on the specified type attribute value. The following values are possible with the shipped distribution (subject to user supplied extension):

mem: Store without real persistence. A repository with a mem store can function properly as long as the the server is not restarted. No additional attributes are recognized.

db: Store that connects via JDBC to a relational database and manages persistent revisions and models through a built-in O/R mapper, see CDO/DB Store. A DB store element can contain the following nested elements:

Property connectionKeepAlivePeriod

Specifies, if the store is a DBStore, at what interval the store will issue an SQL statement to keep the connection to the database alive.

Property readerPoolCapacity

Specifies, if the store is a DBStore, the maximum number of store accessors (JDBC connections) to keep in the reader pool. The default value is 15.

Property writerPoolCapacity

Specifies, if the store is a DBStore, the maximum number of store accessors (JDBC connections) to keep in the writer pool. The default value is 15.

Element mappingStrategy

This element is recognized by DB stores and defines the overall mapping strategy of the built-in O/R mapper.

The type attribute corresponds to the type of a mapping strategy factory that is contributed via the org.eclipse.emf.cdo.server.db.mappingStrategies extension point. The following values are possible with the shipped distribution (subject to user supplied extension):

horizontal: Mapping strategy that creates one DB table per concrete model class. The following nested property elements are recognized: