2.1.1.3. Workspace

Workspace configuration

Workspace data container configuration

Workspaces configuration with system properties

You can configure values of properties defined in the repository-configuration.xml file using System Properties. This is quite helpful especially when you want to change the default configuration of all the workspaces. For example, if you want to disable the rdms indexing for all the workspace without this kind of improvement, it is very error prone. For all components that can be configured thanks to properties such as container, value-storage, workspace-initializer, cache, query-handler, lock-manager, access-manager and persister; the logic, for example, for the 'container' component and the 'foo' property will be the following:

  1. If you have a system property called exo.jcr.config.force.workspace.repository_collaboration.container.foo that has been defined, its value will be used for the configuration of the 'repository' repository and the 'collaboration' workspace.

  2. If you have a system property called exo.jcr.config.force.repository.repository.container.foo that has been defined, its value will be used for the configuration of all the workspaces of the 'repository' repository except the workspaces for which you configured the same property using system properties defined in #1.

  3. If you have a system property called exo.jcr.config.force.all.container.foo that has been defined, its value will be used for the configuration of all the workspaces except the workspaces for which you configured the same property using system properties defined in #1 or #2.

  4. If you have a 'foo' property configured for the 'repository' repository and the 'collaboration' workspace and you have no system properties corresponding to rule #1, #2 and #3, use this value (current behavior).

  5. If the previous rules do not allow giving a value to the 'foo' property, you will then check the default value in the following order: exo.jcr.config.default.workspace.repository_collaboration.container.foo, exo.jcr.config.default.repository.repository.container.foo, exo.jcr.config.default.all.container.foo.

To turn on this feature, you need to define a component called SystemParametersPersistenceConfigurator. A simple example:


  <component>
      <key>org.exoplatform.services.jcr.config.SystemParametersPersistenceConfigurator</key>
      <type>org.exoplatform.services.jcr.config.SystemParametersPersistenceConfigurator</type>
      <init-params>
      <value-param>
      <name>file-path</name>
      <value>target/temp</value>
      </value-param>
      <values-param>
      <name>unmodifiable</name>
      <value>cache.test-parameter-I</value>
      </values-param>
      <values-param>
      <name>before-initialize</name>
      <value>value-storage.enabled</value>
      </values-param>
      </init-params>
      </component>

To make the configuration process easier, here you can define thee parameters.

  1. file-path: this is a mandatory parameter which defines the location of the file where all parameters configured on the previous launch of AS are stored.

  2. unmodifiable: this defines the list of parameters which cannot be modified using system properties.

  3. before-initialize: this defines the list of parameters which can be set only for not initialized workspaces (for example, during the first start of the AS).

The parameter in the list have the following format: {component-name}.{parameter-name}. This takes affect for every workspace component called {component-name}.

Take into account that if this component is not defined in the configuration, the workspace configuration overriding using system properties mechanism will be disabled. In other words, if you do not configure SystemParametersPersistenceConfigurator, the system properties are ignored.

Copyright ©. All rights reserved. eXo Platform SAS
blog comments powered byDisqus