You are looking at documentation for an older release. Not what you want? See the current release documentation.
name: The name of a
workspace.
auto-init-root-nodetype: DEPRECATED.
The node type for root node initialization.
container: Workspace data container (physical storage) configuration.
initializer: Workspace initializer configuration.
cache: Workspace storage cache configuration.
query-handler: Query handler configuration.
auto-init-permissions: DEPRECATED
.Default permissions of the root node. It is
defined as a set of semicolon-delimited permissions containing a group of
space-delimited identities (user, group, etc, see Organization service
documentation for details) and the type of permission. For example, any
read; :/admin read; :/admin add_node;
:/admin set_property; :/admin remove means
that users from group admin have all
permissions and other users have only a 'read' permission.
Workspace data container configuration
class: A workspace data container
class name.
value-storages: The list of value
storage plugins.
properties: The list of properties
(name-value pairs) for the concrete Workspace data container.
trigger-events-for-descendants-on-rename
| Indicate if it is needed to trigger events for descendants on rename or not. This increases the performance of the "rename" operation. However, Observation will not be notified to have the default value as "true". |
lazy-node-iterator-page-size
| Indicate the page size for lazy iterator. Particularly, this property defines the number of nodes which can be retrieved from storage per request. The default value is "100". |
acl-bloomfilter-false-positive-probability | ACL Bloom filters desired false positive probability. Range is between [0..1] and the default value is "0.1d". |
acl-bloomfilter-elements-number | Define the expected number of ACL-elements in the Bloom-filter. Its default value is 1000000. |
Bloom filters are not supported by all the cache implementations so far, only the implementation for infinispan supports it.
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:
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.
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.
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.
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).
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.
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.
unmodifiable:
this defines the list of
parameters which cannot be modified using system properties.
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.