Consuming Configuration¶

Simple Configuration Options¶

Developers have accessed the simple properties via

1. System.getProperty(...) for JVM system property settings
2. SettingsServiceBean.get(...) for database settings and
3. SystemConfig.xxx() for specially treated settings, maybe mixed from 1 and 2 and other sources.
4. SettingsWrapper, reading from 2 and 3 for use in frontend pages based on JSF

As of Dataverse 5.3, we start to streamline our efforts into using a more consistent approach, also bringing joy and happiness to all the system administrators out there. This will be done by adopting the use of MicroProfile Config over time.

So far we streamlined configuration of these Dataverse parts:

• ✅ Database Connection

Complex Configuration Options¶

We should enable variable substitution in JSON configuration. Example: using substitution to retrieve values from MicroProfile Config and insert into the authentication provider would allow much easier provisioning of secrets into the providers.

Why should I care about MicroProfile Config API?¶

Developers benefit from:

• A streamlined API to retrieve configuration, backward-compatible renaming strategies and easier testbed configurations.
• Config API is also pushing for validation of configuration, as it’s typesafe and converters for non-standard types can be added within our codebase.
• Defaults in code or bundled in META-INF/microprofile-config.properties allow for optional values without much hassle.

System administrators benefit from:

• Lots of database settings have been introduced in the past, but should be more easily configurable and not rely on a database connection.
• Running Dataverse in containers gets much easier when configuration can be provisioned in a streamlined fashion, mitigating the need for scripting glue and distinguishing between setting types.
• Classic installations have a profit, too: we can enable using a single config file, e.g. living in /etc/dataverse/config.properties.
• Features for monitoring resources and others are easier to use with this streamlined configuration, as we can avoid people having to deal with asadmin commands and change a setting comfortably instead.

Adopting MicroProfile Config API¶

This technology is introduced on a step-by-step basis. There will not be a big shot, crashing upgrades for everyone. Instead, we will provide backward compatibility by deprecating renamed or moved config options, while still supporting the old way of setting them.

• Introducing a new setting or moving and old one should result in a key dataverse.<scope/task/module/...>.<setting>. That way we enable sys admins to recognize the meaning of an option and avoid name conflicts. Starting with dataverse makes it perfectly clear that this is a setting meant for this application, which is important when using environment variables, system properties or other MPCONFIG sources.
• Replace System.getProperty() calls with either injected configs or retrieve programmatically if more complex handling is necessary. If you rename the property, you should provide an alias. See below.
• Database settings need to be refactored in multiple steps. First you need to change the code retrieving it to use MicroProfile Config API instead (just like above). Then you should provide an alias to retain backward compatibility. See below.