enhancement
major
minor
defect
critical
major
minor
major
#30268
System Environment: Display the source of configuration variables and set variables from the administration interface
Context
An application's configuration contains configuration variables (aliases such as %STORAGE_PATH%). Their definition can specify which environment variable or system property the value comes from, and what default value applies otherwise, e.g., ${env:tl_storage_path:%APP_ROOT%/WEB-INF/app-data}. A variable without such an expression could only be changed via the installation’s own configuration file. The administration system environment listed the variables only with their resolved values; it was not possible to determine which environment variable set a configuration variable, since DefaultAliasManager replaced the ${env:…} expression during loading and retained only the result.
In a simple installation (WAR in Tomcat, Debian package), the installation’s autoconf folder(tl_autoconf_dir) is writable by the application; the Service Editor already stores service configurations there.
Behavior
- Each variable can be set via the environment: A configuration variable whose definition does not contain a ${env:…} expression is implicitly read from the JNDI value, the system property, or the environment variable tl_<name>: the name of the variable without `%,` in lowercase, with every character other than letters, digits, and `_ ` replaced by `_` (%ATTIC_PATH%` → tl_attic_path, %LDAP_URL% → tl_ldap_url). Its value replaces the entire definition. A variable with a ${env:…} expression is set only via the names specified there. Variables set programmatically (%APP_ROOT%, %APP_CONTEXT%, %LOCAL_HOST_NAME%) are excluded.
- “Configuration Variables” view (React interface, Administration → System, next to “Secrets”): For each configuration variable, it displays the environment names through which it is set (an implicit name is marked), the source of the current value (JNDI, system property, environment variable (including its name), the value stored in the application, or the definition), the current value, the default value from the definition, the stored value, and whether a restart is required. The configuration variables no longer appear in the system environment table, which displays system properties and VM arguments.
- Setting from the application: “Set Value” and “Remove Stored Value” save or remove the value of the selected variable in the `variables.properties` file in the `autoconf` folder. The change takes effect only after a restart; the view indicates this, names the file, and highlights variables with pending changes. The autoconf folder belongs to a node; in a multi-node installation, a value set in this way applies only to that node. If the last value is removed, the file is deleted.
- Priority: JNDI, then system property, then environment variable, then the value stored in the application, then the definition with its defaults. If the variable is set via the environment, the view does not offer the option to set it and states the reason; a stored value that is thus masked can be removed.
- No secrets: Variables whose names match one of the protected patterns display their values as hidden and cannot be set or removed; secrets belong in the secret store (#30267).
Technical Notes
- AliasManager is responsible for the variable-to-environment-name mapping and is the only place that evaluates ${env:…}. When resolving, it records a description for each configured variable (AliasDefinition: verbatim definition, environment names—implicit or explicit—, default value, origin AliasSource with name, value at startup, stored value, current value, pending change) and makes them available via getDefinition(name) / getDefinitions(). implicitEnvironmentName(name) returns the implicit name.
- canStoreValues(), storeValue(name, value), removeValue(name), and getStoredValuesFile() (constant STORED_VALUES_FILE) manage the file atomically; the folder is determined as for the Service Editor (tl_autoconf_dir, otherwise WEB-INF/autoconf of the web application) and created if necessary.
- The check for protected names is performed by ` SystemEnvironmentBuilder.protectedNames() ` and is shared by the system environment and configuration variables.
- The view admin/system/config-variables.view.xml (dialog set-config-variable.view.xml) uses the TL-Script functions configVariable… (ConfigVariableFunctions).
- The developer article `configuration-variables ` (com.top_logic.basic) describes definitions, environment names, precedence, and stored values.
Migration
- A configuration variable that overrides an application’s value with a fixed value without a ${env:…} expression (e.g. , <alias name="%STORAGE_PATH%" value="./data"/>) to override a value set via the environment in the base definition will now nevertheless be replaced by tl_<name> from JNDI, a system property, or the environment (in this case, tl_storage_path). If you want the fixed value to apply even when the environment sets tl_<name> (such as in a Docker image that sets tl_storage_path ), remove the variable from the installation’s environment or set the desired value there.