Delta configuration

As of version 11.0.1, WorldServer consists of three components: the new web interface (ws), the new REST API (ws-api) and the legacy application (ws-legacy). In previous 10.x versions, you could specify a certain configuration value only in one place (i.e. classpath). However, starting from version 11.0.1, you can customize configuration files in different locations and you no longer need to have a copy of the entire configuration file. The wsconfig folder should contain only the properties configured for that specific environment. Moreover, configuration properties can now be shared between components (ws, ws-api, and ws-legacy), because WorldServer uses three layers of configuration with given priorities, as explained below. This mechanism makes the upgrade process easier and it separates out-of-the-box configuration values from custom configuration values.

You can set WS_CONFIG in two ways:
  • As a system variable (also known as an environment variable) that will point to the configuration directory.
  • As a Java system property (e.g. -DWS_CONFIG=<WS_CONFIG path>); if you set it as a Java system property, it has priority over the system variable.
If you set WS_CONFIG as a system variable, three layers of configuration will be merged when searching for a configuration key:
  1. %WS_CONFIG%/<application-part-name> (where<application-part-name> is one of: ws, ws-api, or ws-legacy). This layer should contain configuration values specific to each component.
  2. %WS_CONFIG%. This layer should contain configuration values shared between components.
  3. classpath. This layer contains out-of-the-box configuration values and should not be modified.

When trying to get a configuration value, the framework will search in the configuration files in the above order, returning the most specific value and ignoring the others.

Recommended configuration
  • The Tomcat application folder— the values are configured by default for all files.
  • %WS_CONFIG%/general.properties — the common general.properties. It should contain the database connection values (if you do not use Windows registry), temp_dir value, session_timeout and other configurations you want to change for the WorldServer engines. Also, this configuration should contain the navigation.panel.url = <link_to_new_ws_interface>.
  • %WS_CONFIG%/ws-api/general.properties — specific configurations for ws-api. The ws-api value should always be workflow_daemon=0 and disabled notification_engine and recurrence_engine (workflow daemon, notification_engine and recurrence_engine will only be serviced by ws-legacy) and at least one background_daemon.
  • %WS_CONFIG%/ws-legacy/general.properties — specific configurations for ws-legacy. ws-legacy should always have workflow_daemon number configured and notification_engine and recurrence_engine enabled.
  • %WS_CONFIG%/ws-api/api.properties — REST API configurations.
  • %WS_CONFIG%/ws/ui.properties — UI configurations. You must provide values for configurations: ws.legacy.url, ws.api.url, ws.api.version.
We do not recommend having specific general.properties for ws. Being decoupled from ws-legacy code, only the following configurations from general.properties will be read:
  • session_client_check
  • use_http_only_cookies
  • use_secure_urls
  • temp_file_path
  • password_autocomplete.
This is the minimal configuration that you need in order to run WorldServer. The other configuration values are set by default. If you want to customize other configuration files, we recommend putting them in %WS_CONFIG% so that ws-legacy and ws-api will be able to access them. However, we do NOT recommend changing the configuration files in the classpath (the expanded war in Tomcat).

If you encounter any issues related to configurations, please refer to the Troubleshooting configuration issues section.