Skip to end of metadata
Go to start of metadata

ModeShape is not included with JBoss Wildfly, so none of the standard configurations include any ModeShape configurations. However, once ModeShape is installed into Wildfly, it's easy to add ModeShape to any Wildfly configuration.

Since the number of ModeShape configuration elements for Wildfly is very large, this page only provides some general configuration guidelines.
For a full list of elements & attributes we encourage reading/using the latest version of the ModeShape XML schema, which is part of the kit and is located in the docs/schema folder.

Step 1: Start the server

Start your server in standalone mode with your favorite configuration. For example, the following starts with the "standalone.xml" configuration file:

Use the appropriate command for your OS. See the Wildfly documentation for details.

Step 2: Start the server's CLI

JBoss Wildfly has a very nice low-level command line interface (CLI) tool that you can use to directly manipulate the configuration of the running server. If the server is running in domain mode, the CLI will immediately propagate the changes to all the servers.

Start the CLI and connect to your server:

Step 3: Add the ModeShape subsystem

ModeShape is installed, but the current configuration doesn't know about the ModeShape subsystem. So the next step is to add it:

The configuration's XML file (in this case "standalone.xml") is updated immediately. Watch the configuration file as you use the CLI.

Step 4: Add a ModeShape repository

We want to add a repository, but before we do that we need to add or configure the Wildfly resources that the repository will use.

Step 4a: Add a security domain (optional)

This is an optional step as by default ModeShape will integrate with Wildfly's Application Realm. As such, you can simply add users via the add-user server script, as described here.

However, ModeShape can also use any security domain, as long as the domain defines the correct ModeShape roles for each user.

For example, since none of the out-of-the-box security domains includes these roles, let's create our own security domain that uses 2 properties files: modeshape-users.properties and modeshape-roles.properties files which should be placed in the JBOSS_HOME/standalone/configuration folder and should have the following content:

modeshape-users.properties

and

modeshape-roles.properties

Once you've created these files in the above location, run the following commands:

We need to reload the services for these changes to take effect:

JBoss Wildfly supports multiple kinds of security domains, including integration with LDAP and even single sign-on using the local OS. Consult the JBoss Wildfly documentation for details.

Step 4b: Add the repository

Now that we've finished defining the services that our repository will use, we can define our ModeShape "sample" repository:

This command configures the repository to use the "modeshape-security" security domain we created earlier.

We actually didn't need to define the security-domain="modeshape-security" attribute because the repository would use a security domain with that name by default. Specifying it doesn't hurt, but any attributes that match the default value will not be serialized to the XML configuration file.

Note that defining a repository doesn't require restart. In fact, quite a few of the ModeShape administrative operations can take effect immediately, even when applications are actively using the repository.

Step 4c: Add the persistent store

The repository created in the previous step will only store data in memory. To make it store data on disk, we add a file persistent store

Advanced configuration

With just a few commands, you can add a repository that will persist content locally. However, more advanced configuration options are available.

Advanced repository configuration

At any point, we can see the complete definition of a repository:

This shows all of the attributes, including those that are not set or set to their default values. To see more detail about each attribute and child, use the ":read-resource-description()" command:

We didn't show all of the output, since it's quite long. But each attribute is described and shows the criteria for valid values, whether expressions (e.g., system variables) are allowed, and whether a restart will be required before changes take effect.

Most of the attributes do have defaults, but some of these defaults are not listed in the descriptions because the defaults are functions of other attributes. For example, every repository is registered in JNDI under "jcr/repositoryName", and also under the JNDI name explicitly set with the "jndi-name" attribute.

At this point, any deployed application can use the repository (see the the chapter) for details).

Add and remove sequencers

You can use the CLI to dynamically add and remove sequencers. Here's an example that adds to the "sample" repository a sequencer that operates against comma-separated value (CSV) files uploaded under the "/files" node:

Note how this particular sequencer has an additional "splitPattern" property that specifies the delimiter.

To remove a sequencer, simply invoke the "remove" operation on the appropriate item:

Specify indexing configuration

TODO

Specify where large binary values are stored

In the same way you specify index storage above, you first need to add the binary storage resource to your configuration:

Once the binary storage node is added, you can add the storage type with required/optional parameters:

If you configure binaries to be stored on disk, the path attribute from above always represents *a relative path* to the jboss.data.dir by default. You can specify another root directory by using the relative-to attribute.

Configuring a composite binary store

Composite binary stores are different from the rest of the standard binary stores, because they can aggregate any number of standard binary stores. Therefore configuring them via CLI is a bit different.

First, you need to configure the composite binary store in similar fashion to any other binary store:

After this, you need to make sure that each nested store has a store-name property which is unique within the composite store and that the appropriate resource-container is used when adding the store.

Corresponding to each of the standard binary stores, the following resource-containers are available:

  • nested-storage-type-file - for file system binary stores
  • nested-storage-type-db - for database binary stores
  • nested-storage-type-custom - for custom (user defined) binary stores

For example, if you wanted to add a file system binary store to a composite store, you would run:

If you wanted to remove this store, you would run:

Add and remove authentication and authorization providers

You can use the CLI to dynamically add and remove custom authentication and authorization providers. For example, if your org.modeshape.jcr.security.AuthorizationProvider implementation were named "org.example.MyAuthProvider" and were added to a new "org.example.auth" module, then the following command would add this provider to the "sample" repository:

To remove an authentication provider, simply invoke the "remove" operation on the appropriate item:

ModeShape can set instance-level fields on the provider instances. For example, you might want to set the "auth-domain" field on the MyAuthProvider instance to the String value "global". To do this, simply add them via the "properties" parameter (which is a list of documents that each contain a single name-value pair):

When running in JBoss AS, ModeShape will always use some built-in security providers required in order to integrate with the application server's security domain (see Step 4a: Add a security domain). This means that these providers will always be invoked during the authentication / authorization process for any given user. However, when adding custom providers to the configuration, ModeShape will place those first in the list of authentication providers. So if you want to avoid defaulting to the built-in security providers, make sure your custom providers always decide if a user is authenticated or not.

Add JDBC Data Source

First, you need to add the driver:

Then, the actual datasource:

Add and remove external sources

To enable federation, one or more external sources can be added to an existing repository.

The following example show how using the CLI an external file system source (via the FileSytemConnector) can be linked to the sample repository:

Notice that there are several attributes that can be specified when adding an external source:

  • classname (mandatory) - the fully qualified name of the Connector class which allows content to be retrieved and written to that external source
  • module (optional) - the name of the Wildfly module where the above class can be found
  • projections (optional) - a list of projection expressions representing predefined projection paths for the source; projections can either be defined here or programmatically using the FederationManager.createProjection(...) method.
  • queryable (optional) - a flag indicating if the content exposed from the external source should be indexed by the repository or not. By default, all content is queryable.
  • readonly (optional) - a flag indicating if only reads or both reads and writes are possible on the source
  • properties (optional) - an array of key - value pairs which allow any custom attributes to be passed down on the Connector implementation class.

To remove an external source, just invoke remove on that source:

Add dependency on other modules and deployment units

When resolving configuration options which refer to external files and resources, ModeShape will use at runtime the class loader of the org.modeshape.main module. However, this class loader is isolated (cannot access) any resources which are available to another server module on which ModeShape does not explicitly depend.

In these particular cases, you can add a depends-on repository attribute which is a comma-separated list of module names which ModeShape will use in addition to its default class loader when attempting to load external files and resources.

For example, with the following configuration:

the repository externalDependenciesRepository will be able to load the files initial-content-cars.xml and cars.cnd from the deployed external-dependencies.war, when those files are packaged inside the war file under the WEB-INF/classes/config folder.

Batch mode

You can combine all these commands (except for the initial /extension=org.modeshape:add() command) into a batch operation:

Batches can be stashed or edited before they are run, and multiple commands can be easily pasted into a batch.

Clustering

Configuration

The same rules apply here as for the clustering configuration in standalone Java applications with the only difference being the attribute names.

You can choose whether to use the JGroups stacks defined in JBoss AS or provide an external JGroups configuration file (identical to the one from the standalone example).

In the former case, your clustering configuration would look like:

In this case, before configuring ModeShape to run in a cluster, make sure the JGroups subsystem is present in the Wildfly configuration:

In the latter case, your configuration would point to an external JGroups file:

CLI example

To configure a cluster repository via CLI, you could run the following commands in order:

1) Main repository

This configuration uses the tcp JGroups stack defined inside the application server.

2) Binary Storage

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.