Configuring Platform properties and Spring profiles

The configuration files for LuciadFusion Platform are in the config folder of the distribution. The LuciadFusion Platform is based on the Spring framework for system and application development, and uses YAML configuration files with file names that have the following format: application-<profile name>.yml.

Spring profiles allow you to segregate parts of the application configuration and make them available only when they are activated. This comes in handy when you want different property values for different environments. You can activate profiles in the usual way, by setting Spring properties, for example:

  • In application.yml: spring.profiles.active: fusion.single,fusion.production

  • On the command line: --spring.profiles.active=fusion.single,fusion.production

For more information about externalized configuration and property resolving order in Spring Boot, go to: https://docs.spring.io/spring-boot/docs/2.1.0.RELEASE/reference/html/boot-features-external-config.html.

Property ordering rules

Spring imposes the way in which property values are resolved.

In consequence, the properties defined in the YAML files can be overwritten by JNDI attributes (from java:comp/env) for example, and those can in turn be overwritten by command-line arguments.

LuciadFusion profiles

The config folder contains the following files:

  • A fusion.development profile in application-fusion.development.yml: this application profile contains configurations that allow you to get a server application up and running. It is used when you start LuciadFusion Platform via start.jar. It is mainly suited for development, and should not be used for production environments.

  • A fusion.production profile in application-fusion.production-template.yml: you must use this configuration file as a basis for production. It lists all properties that must have a value before you build the application. See Configuring LuciadFusion Studio for more information. Some of those properties are mandatory. Others are optional.

  • A fusion.common profile in application-fusion.common.yml: this optional file can be used to overwrite the default values set in the fusion.single profile. This profile is included in both application-fusion.development.yml and application-fusion.production-template.yml, so it can be used for settings that are shared between both profiles.

The fusion.single profile must always be included in the list of active profiles in the spring.profiles.active property. This profile contains sensible default property values to run all LuciadFusion services on one (single) server instance.

The profile YAML files in the list contain documentation for each property. This guide gives an overview of the most important properties.

Recommended practice for profiles

Create a specific profile for each environment. For example:

  • development environment: application-fusion.development.yml

  • production environment: application-fusion.production.yml

  • test environment: application-fusion.test.yml

  • staging environment: application-fusion.staging.yml

These profiles are modified copies of application-fusion.production-template.yml. They all include the same fusion.common profile.

The deploy environment of the application server determines how you set active profiles. For example, for the staging environment: spring.profiles.active=fusion.single,fusion.staging The properties that are configured in both the fusion.single profile and the fusion.staging profile (and its included fusion.common profile) will be resolved from left to right. That means that the re-defined properties of fusion.single will be overwritten.

General configuration

Each service is enabled by default and can be disabled by setting the <service prefix>.enabled: false. For example, to disable the OGC WMS service in the application-fusion.common.yml file: fusion.ogc.wms.enabled: false

Configuring security

The LuciadFusion Platform comes with a number of ready-to-use security configuration options.

The property fusion.security.enabled is set to true by default. If the built-in security in the LuciadFusion Platform is enabled, the following properties need to be set:

  • fusion.security.cors.origins: Comma-separated list of origins to allow. '*' allows all origins.

  • fusion.security.authenticationManager: Possible values are authenticate_all, properties_in_memory, ldap_ad, ldap.

  • fusion.security.authenticationTypes: Possible values are form, http_basic, no_auth.

The pre-defined authentication types are:

  • form: Enables form based authentication, using cookies to track a user’s session

  • http_basic: Enables HTTP Basic authentication

  • no_auth: Disables authentication

The pre-defined authentication managers are:

  • ldap_ad: for performing user authentication against an Active Directory server.

  • ldap: for performing user authentication against a LDAP server.

  • properties_in_memory: for defining users within the configuration file. This is not recommended in a production environment.

Each of the options has its own set of configuration settings. Within the configuration file, they are organized by authentication type.

Using your own authentication system

You can still configure the security for your own authentication system, if the available options do not suffice. First, disable the default LuciadFusion security by setting fusion.security.enabled to false. You can then use your own security configuration, through the Spring Boot Security Java configuration. If you only disable the LuciadFusion security, and do not configure your own security, Spring Boot Security will use a default fallback: basic authentication on all HTTP endpoints and a single user, with user as the user name and a random password that is printed in the logs at INFO level with the text "Using generated security password".

For more information about Spring Boot Security, go to https://docs.spring.io/spring-boot/docs/2.1.0.RELEASE/reference/html/boot-features-security.html. For a general overview of Spring Security, see https://spring.io/guides/topicals/spring-security-architecture/

You can also configure SSL in LuciadFusion. See application-fusion.production-template.yml for more information.

Configuring logging

Logging is configured as follows:

  • The fusion.development and fusion.production profiles (config/application-fusion.common.yml) refer to the logging configuration using the logging.config property. By default, it refers to the config/fusion.logback.xml file.

  • The config/fusion.logback.xml file contains the default logging configuration for LuciadFusion. It defines to which file the logs are written, and which levels are used for console logging and for file logging. It is possible to modify or replace this file. See config/fusion.logback.xml for more information on how to change the configuration.

Modifying the port

Depending on how LuciadFusion Platform is used, the port should be configured differently.

  • If you are using the LuciadFusionPlatform.zip file generated by the deployment script or the startup script that is shipped with the release, you can modify the port by changing the server.port property in the fusion.development profile (config/application-fusion.development.yml).

  • If you are deploying the LuciadFusionPlatform.war file generated by the deployment script on a servlet container, refer to the documentation of the servlet container, for example Apache Tomcat or Jetty.

Configuring Studio

For Studio, you can find the production properties that require a value in application-fusion.production-template.yml and the development properties in application-fusion.development.yml. Shared Studio properties are listed in application-fusion.common.yml.

Configuring OGC services

The OGC service properties are explained in the file application-fusion.common.yml The property prefix of the OGC services is fusion.ogc.<ogc service>. These settings include:

  • Properties to enable or disable services. If you want to disable a service, set fusion.ogc.wcs.enabled: false for example.

  • The OGC WMS and WMTS tile caching settings.

  • The configuration of metadata auto-generation and OGC CSW server settings such as the INSPIRE profile.

All OGC services properties are listed in application-fusion.common.yml.

Configuring the Tiling Engine and the LTS service

The most important property of the Tiling Engine is fusion.engine.tilestoreHome, to be found in application-fusion.production-template.yml. It is required for the production profile and has ${fusion.studio.configuration.uploadPath}/coverages as default value. The dollar sign and the curly braces indicate a reference to other properties in the YAML files.

The optional parameters for the tiling service can be found in application-fusion.common.yml.

Configuring the symbology service

The Symbology Service is a servlet that serves military MS2525/APP6 icons with specified styling information. LuciadRIA, the Luciad browser solution, needs to have access to this service. Without it, the luciad.symbology.military.MilitarySymbologyPainter does not function properly.

You can customize the symbology service to use a specific default style, and clients can request icons with both custom and default styling. The configuration options can be set in the application-fusion.common.yml file.

Setting the default styling parameters

The default styling parameters file contains a list of styling parameters values and their values. You can manually override the default styling values for each query.

Table 1. Available styling parameters with their default values

Parameter Key

Default Value

Possible Values

Symbol.Frame

true

true, false

Symbol.Fill

true

true, false

Symbol.FillPercentage

1.0

Floating point number between 0.0 and 1.0

Symbol.Icon

true

true, false

Symbol.HaloSize

0

Positive integer [0,1,2…​]

Symbol.HaloColor

rgb(255,255,255)

RGB color [rgb(0,0,0), rgb(128,0,128),…​]

Symbol.AffiliationColorEnabled

true

true, false

Symbol.Size

32

Positive non-zero integer […​31,32,33…​]

Defining affiliation colors

The affiliation colors configuration file contains a list of affiliation types. Each type is mapped to a specific color. The colors are defined as RGB color codes, specifying each color component as an integer between 0 and 255. An overview of the default colors is available in the following table:

Table 2. Available affiliation color parameters with their default values

AFFILIATION_PENDING

rgb(255,255,128)

AFFILIATION_UNKNOWN

rgb(255,255,128)

AFFILIATION_ASSUMED_FRIEND

rgb(128, 224, 255)

AFFILIATION_FRIEND

rgb(128, 224, 255)

AFFILIATION_ASSUMED_NEUTRAL

rgb(171, 255, 171)

AFFILIATION_NEUTRAL

rgb(171, 255, 171)

AFFILIATION_SUSPECT

rgb(255, 128, 128)

AFFILIATION_HOSTILE

rgb(255, 128, 128)

AFFILIATION_EXERCISE_PENDING

rgb(255,255,128)

AFFILIATION_EXERCISE_UNKNOWN

rgb(255,255,128)

AFFILIATION_EXERCISE_ASSUMED_FRIEND

rgb(128, 224, 255)

AFFILIATION_EXERCISE_FRIEND

rgb(128, 224, 255)

AFFILIATION_EXERCISE_ASSUMED_NEUTRAL

rgb(171, 255, 171)

AFFILIATION_EXERCISE_NEUTRAL

rgb(171, 255, 171)

AFFILIATION_JOKER

rgb(255, 128, 128)

AFFILIATION_FAKER

rgb(255, 128, 128)

If the affiliation configuration file is not available, because it is not linked in the web.xml file or because it does not exist, the servlet will use a sensible default.