Introduction / FirstSpirit ServerManager / Server properties / Modules


Activate autostartStart serviceStop serviceUpdating usesVisibilityTypeModule nameConfigureVersionUninstallInstall / Update
Table of contents

FirstSpirit modules can be installed and configured in this area. Initially, the module “System” (folder icon) is present with the standard components. The modules are displayed in alphabetical order (by module name).

Important When installing and updating modules that are either the basis for data themselves or are the basis for the data via directly or indirectly dependent services, these data are no longer available to these processes until the processes are accessible after restarting (generations, clients, etc.).
Important When updating a module, existing module resources that are in use outside the module remain accessible. This allows module updates to be carried out during operation.
It is recommended to restart the server after a module update, as this is the only way to ensure that only resources from the currently installed module versions are used.



Name of the module or name of a component of the module. The modules can be identified in the dialog by the folder icon. Each module has one or more components that are displayed under the module. Components can be identified by the file icon. There are different types of components (see “Type”).


The version number of the module or of the component installed on the FirstSpirit server.


Type of component. A distinction is made between the following components:

  • Library: a library is a non-configurable collection of classes packed in one or more jar files. After installation they are available on the FirstSpirit server, within the clients, in scripts and other modules.
  • Editor: an editor is a combination of GUI and rendering components. The editor is used to expand FirstSpirit Client to include custom input options. (Example: the CMS_INPUT_PERMISSION input component for defining permissions, see Chapter User permission configuration. This input component works with the relevant service that loads and provides the server group definitions.)
  • Service: a service is a server component that can be activated via a public interface composed of input components or scripts. (Examples include Spell checking or the CMS_INPUT_PERMISSION permissions input component service.)
  • Web application:a web application defines JSP tags and servlets that can be used and called in projects. (DynamicPersonalization and Search are examples of web applications.)
  • Web server: a web server component provides functions for installing and uninstalling web applications. (Examples include the internal web server control or Tomcat support, for more information, see Web server.)


Components are available after installation only in a specific area. A distinction is made between the following areas:

  • Global: global (system-wide) components are available on the server after installation; this ensures that these components are also available in all scripts and other components within FirstSpirit applications (examples: all services; e.g. the permission service).
  • Project: after installation, local project components can be added to the desired projects via their project properties (see Web components). The user then has the option of configuring these components. Configurability depends on the installed component.
  • Web: after installation, local web components can be added to the individual web areas (preview, staging, live) within the desired projects (see Web components). Configurability depends on the installed component. The components can be configured differently for the respective projects.


Install /Update

Cicking on the Install button opens a file selection dialog. Here you can select the fsm file that is to be installed (such as the FirstSpirit DynamicPersonalization module. The successfully installed file is then displayed in the “Server properties” dialog (see Figure above).

If the installed component contains a service, a dialog where the Autostart option for the service can be configured is also displayed.  If the dialog is confirmed by clicking on Yes, the service is started automatically every time the server is restarted (see option “Activate/deactivate Autostart”, below).

If a newer version of the module is available, the module can also be updated using the Installation button on FirstSpirit Server. It is not necessary to uninstall the module beforehand. Although the original configuration is preserved, adjustments in the configuration settings or within the projects using the module may be required. A new version of the module is therefore not imported automatically to the projects, and updating within a project must be carried out manually (see Project components and Web components). The uses can be modified using the Update uses button. 

Important After updating modules that have dependencies to modules with services, these services need to be restarted manually (using the Stop services / Start services buttons, see below or ServerMonitoring, see Services).


To uninstall a particular module, select it from the overview of installed modules and click on this button. The module “System” (folder icon) cannot be uninstalled.

Only modules that are not being used in a project can be uninstalled. When attempting to uninstall a module that is still in use, an error message will appear containing a list of all projects currently using the module. The module must first be removed from these projects before it can be uninstalled (see Web components).


Use this button to configure the selected component. Configurability depends on the selected component (see SpellService for an example). Permissions can be set for a module as well (see section Trusted modules):

Update uses

The Update uses button is available for convenient updating of a module contained a project or web application. Clicking on the button opens a dialog box where the project or web applications for all projects that have been using this module can be updated:

Updating projects does not have to be carried out only through their individual project properties; the update can also be controlled centrally using the server properties.

Start service

Clicking this button starts a service manually. Services can also be started manually via ServerMonitoring (see Services).

Important After updating modules that have dependences on modules with services (“Service”), these services need to be restarted manually.

Starting services automatically:

  • Starting all services automatically: By configuring SERVICES=* in the fs-server.conf configuration file, all the services installed on the server are started automatically when the server itself starts (see Services parameter documentation).
  • Starting certain services automatically: Activate the services that are to be started via the Autostart option in ServerManager (see below) or the Autostart option in ServerMonitoring.

Stop service

Click on this button to stop a started service. A service can also be stopped in ServerMonitoring (see Services).

Activate autostart / Deactivate autostart:

Clicking the corresponding button activates or deactivates the automatic start function. If the Activate autostart option is selected, the service will start automatically each time the server restarts. If the Deactivate autostart option is selected, the service will need to be started manually each time the server restarts. This setting can also be configured initially when installing or updating services.

If all the services installed on the server are to be started automatically when the server itself starts, this can be achieved by configuring SERVICES=* in the fs-server.conf configuration file (see Services parameter documentation).

Important Many of the features documented above can also be implemented via the FirstSpirit Developer API (ModuleAdminAgent interface, package).

Further configuration options

Trusted modules

FirstSpirit SiteArchitect and FirstSpirit ServerManager are started via the FirstSpirit Launcher. This results in limitations when using some functions for modules not signed by e-Spirit or classes in the jar archives. Java programs usually run in a “sandbox”. This means that they do not have complete access to the computer (and its resources) on which they are run. Access to local resources such as files, the clipboard, network, etc. is through a security manager.

The internal FirstSpirit modules are signed with an “e-Spirit AG” key. This is a component of the internal FirstSpirit security policy. In addition, the key is confirmed by a root authority that is in turn recognized by the Java certificate manager.

External components or modules that access security-related functions can be configured easily using FirstSpirit ServerManager. Each module installed (except for the FirstSpirit system modules) can optionally include permissions to the local system resources. This makes it possible to trust a module that carries out security-related operations, i.e. access to the clipboard (java.awt.AWTPermission ClipboardAccess). Permissions to carry out operations can be assigned to this module. This takes place internally through the FirstSpirit Security Manager/Classloader.

The configuration screen where the module permissions are set in the FirstSpirit ServerManager appears as follows:

Important If an external component or a module is classified as trusted, there is no assurance that the FirstSpirit secure access mechanisms will be fully effective. Any malfunctions that may occur can no longer be attributed to a clear cause, making an error difficult or impossible to diagnose. As part of FirstSpirit product maintenance, system configurations classified as trusted external components or modules are therefore not permitted.

For more information, see the “FirstSpirit Manual for Developers (Components)” (German only).

Using the FirstSpirit Developer API, user-developed modules can be identified as trusted via the setTrusted method in the ModuleAdminAgent interface ( package) or the trustworthiness can be checked using the isTrusted method.

Dependent modules

It is possible to define dependencies between FirstSpirit modules. This takes place using the entry


in file module.xml of the dependent module (child) (see the “FirstSpirit Manual for Developers (Components)” (German only)).

Modules containing a <dependencies><depends> specification (child) and modules that are referenced by this specification (parent) can be uninstalled from the FirstSpirit server without leaving any traces (“Uninstall” button), even if the dependent module is no longer present on the server (because it has been removed previously, for example).

Child modules whose parent module is not (or no longer) on the server are visualized by means of a corresponding icon:

Dependent modules

A tool tip lists the names of the missing dependent modules.

It is possible to use the isActive method (FirstSpirit Developer API, ModuleAdminAgent interface) to check whether a module has missing references to other modules.

Application configuration

The module folder “System” can be used to configure the visibility for all standard applications for different groups (see also page Start page).

Here you can enter names of external groups whose users should be able to see the applications. The names are defined in the same way as for parameter

in the fs-server.conf file.

If the group is empty, all users can see the corresponding application.

Important This group configuration is always evaluated and overwrites the visibility settings on the start page.

For more information on “External groups” please see also Project properties / Groups.

© 2005 - 2021 e-Spirit AG | All rights reserved. | FirstSpirit 2021-02 | Data privacy | Imprint | Contact us