Modules

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).

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.).

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.

Information

Name

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”).

Version

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

Type

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.)

Visible

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.

Actions

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. 

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).

Uninstall

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).

Configure

Use this button to configure the selected component. Configurability depends on the selected component (see SpellService for an example).

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.

Show Module Issues

Conflict detection takes place when modules are installed and results are logged and visualised accordingly.

In the overview list of modules, problems with and between modules are now visualised.

• (blue): Modules containing resources, which are either unknown or configured for the global classath.
  • “Resource may influence other modules”
    The module contains a resource configured for the global classpath, which no other module does.
  • “Unnamed resource found”
    The module brings a global resource that has no “name” attribute, and thus cannot be identified or compared.
• (red): Modules containing resources, which may have an impact on the functionality of FirstSpirit or the corresponding modules.
  • “Resource may negatively impact other modules”
    The module contains a global resource, that is also contained in at least one other module.
  • “Module may be negatively impacted by global resources”
    The module contains a private resource, which is configured for the global classpath by another module.
  • “FirstSpirit artifact detected”
    The module contains a FirstSpirit artefact, which are already provided at runtime.
• (yellow): Module containing resources in a way that will no longer be supported in the future.
  • “Legacy resource found”
    The module contains a legacy resource.
  • “Web-app component uses legacy Servlet version (< 5.0)”
    The module brings a WebApp component that still uses a Legasy Servlet version.

Note: Only the icon with the highest level of severity is displayed.

The button Show Module Issues can be used to display corresponding conflicts.

Start service

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

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).

Many of the features documented above can also be implemented via the FirstSpirit Access API (ModuleAdminAgent interface, de.espirit.firstspirit.agency package).

Further configuration options

Dependent modules

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

<dependencies>
       <depends>modulename</depends>
</dependencies>

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 and marked in red.

Dependent modules

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

It is possible to use the isActive method (FirstSpirit Access 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

• externalServerAdminGroup

in the fs-server.conf file.

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

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.