Workspace configuration

Once a workspace is created, you can adjust the workspace configuration on a workspace-by-workspace basis. For each new workspace, there is a corresponding workspace.xml file for fine-tuning individual performance. By default, the file is located in the file system inside the corresponding workspace folder.

To modify the configuration of an existing workspace, you need to change the workspace.xml file for that workspace. Changing the <Workspace/> element in the repository configuration file does not affect existing workspaces.

File system

The virtual file system passed to the persistence manager and search index.

<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
  <param name="path" value="${rep.home}/repository" />
</FileSystem>

Jackrabbit provides a lot of choices for how you can configure the FileSystem. Choose the class that best fits your use case.

Persistence manager

Each workspace in a Jackrabbit content repository uses separate persistence managers to store the content in that workspace.

<PersistenceManager class="org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager">
  <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
  <param name="schemaObjectPrefix" value="${wsp.name}_"/>
</PersistenceManager>

Jackrabbit provides a lot of choices for how you can configure the PersistenceManager. Choose the class that best fits your use case.

Search index

Node names and property values are indexed as soon as the data is saved or as soon as the transaction is committed.

Text extraction is done asynchronously in a background thread. That means text that’s changed or added isn’t available immediately, but rather after a short delay. You can configure the exact behaviour using the extractor settings.

Jackrabbit provides the following options in the class SearchIndex. All parameters (except path) have default values and you can omit them and use the default value instead.

See Jackrabbit Search for more details.

Basic configuration

Parameter Description

path

required

The location of the index directory. A reasonable value is: ${wsp.home}/index

indexingConfiguration

optional

When not set, all properties of a node are indexed. Magnolia provides a default indexing configuration file located in the Core module.

indexingConfigurationClass

optional

The name of the class that implements IndexingConfiguration. IndexingConfigurationImpl implements a concrete indexing configuration.

analyzer

optional

Sets the default analyzer in use for indexing. The default value is the StandardAnalyzer.

This analyzer uses an English-language stop word set. Lucene provides language-specific analyzers, which you can configure property-by-property in the indexing configuration file.

directoryManager

optional

The name of the class that implements DirectoryManager. FSDirectoryManager implements a directory manager for FSDirectory instances. RAMDirectoryManager implements a directory manager for RAMDirectory instances.

useSimpleFSDirectory

optional

Indicates whether the DirectoryManager should use the SimpleFSDirectory instead of letting Lucene automatically pick an implementation based on the platform you’re running on. Default is false.

See Jackrabbit search for a general summary of Jackrabbit search in the context of Magnolia. Alternatively, go to the Search index configuration file for specifics on index rules, aggregates, analyzers, and configuration parameters.

Workspace security

Workspace security is handled by the MagnoliaAccessProvider.

See the workspace security section for more details.

Synchronize workspaces between Magnolia instances

When using Magnolia, you often store content in a variety of workspaces. Typically, workspaces are kept under your magnolia.repositories.home in the WEB-INF/config/default/magnolia.properties file. The Content Types module creates node types, workspaces, and namespaces on-the-fly. If using, make sure your repository configuration and workspaces are properly synchronized as this on-the-fly feature makes changes to repository configuration files.

The following should be considered when creating a new content type:

πŸ“ repo

     πŸ“ magnolia

         πŸ“ repository

             πŸ“ datastore

             πŸ“ meta

                 βΈ¬ rootUUID

             πŸ“ namespaces

                 ⬩ ns_idx.properties

                 ⬩ ns_reg.properties

             πŸ“ nodetypes

                 ⬩ custom_nodetypes.xml

             ⬩ db.mv.db

         πŸ“ workspaces

             πŸ“ config

             ⬩ db.mv.db

             ⬩ workspace.xml
Item Notes

Namespace definitions

Found in the repository/namespaces folder, you can find your custom namespace registry and its index which are stored as a text file in ns_idx.properties and ns_reg.properties.

Copy your custom namespace registry and index to the target environment to synchronize them.

Node type definitions

Custom node type definitions are stored in the repository/nodetypes folder in the custom_nodetypes.xml file.

This is not automatically generated if you aren’t starting up a clean Magnolia instance. So you would also have to merge your existing definition (in the target environment) with the one defined there.Otherwise, an invalid nodetype error may occur when accessing content with that nodetype after your data synchronization.

Workspace configuration

Your workspace configuration stores the detailed workspace configuration in the workspaces/<your_workspace_name>/workspace.xml file.

If you want to change the PersistenceManager class, SearchIndex class, excerptProviderClass or AccessControlProvider class, change it in each of your workspace configuration files. These files are then used in the next system startup process.

Index and lock

You can remove all files and folder under the index folder. The system then regenerates, reindexing the entire workspace for you at restart.

Why is this important?

This ensures repository consistency and cleans up all unsynchronized indexes.

For content synchronization, this folder should not be copied over different instances. It need to be cleaned up in the target instance instead.

The actual content

The actual content is typically stored in your configured database tables with the name prefix according to "schemaObjectPrefix" name where {wsp.name} is the workspace name.

For example

  • pm_${wsp.name}_NODE (table)

  • pm_${wsp.name}_NODE_IDX (index)

  • pm_${wsp.name}_PROP (table)

  • pm_${wsp.name}_PROP_IDX (index)

  • pm_${wsp.name}_REFS (table)

  • pm_${wsp.name}_REFS_IDX (index)

  • pm_${wsp.name}_BINVAL (table)

  • pm_${wsp.name}_BINVAL_IDX (index)

Retrieving content

When using the cmsfn Content by template ID function, maxResultSize sets the maximum number of results returned. Choosing a moderate threshold can significantly improve query performance.

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Performance tuning guide docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules