Skip to content

Overview

The goal of this appjar is to manage application-level and user-level configuration values at runtime, allowing the behaviour of the application to be adjusted without code changes or redeployments.

Enterprise applications typically contain many configurable parameters — timeouts, limits, feature toggles, display preferences — that are defined at development time and require a deployment cycle to change. The Configuration Manager appjar addresses this by storing configuration values in the database and providing a dedicated interface for managing them at runtime.

Configuration Types

The appjar distinguishes between two categories of configuration:

  • System Configurations apply globally across the entire application. These are managed exclusively by administrators and take effect for all users.
  • User Configurations are defined at the user level and allow different values to be set for each individual user. Regular users can view and modify their own User Configurations through the My Configurations view.

Values and Data Types

Each configuration entry has a defined data type — STRING, INTEGER, BIG_DECIMAL, BOOLEAN, DATE, or TIME — which determines how the value is stored and validated. Every configuration has a default value that serves as the baseline until an explicit override is set. When no override has been applied, the interface marks the value with a (Default) label.

Values and Application Properties

System Configurations are more than a table of settings: the appjar exposes them to the application as configuration properties. A configuration whose name matches a property key the application reads — through a @Value annotation, for instance — supplies that property's value, taking precedence over the application's own configuration files. This allows a setting that would otherwise be fixed at build time to be adjusted from a screen, and is the reason configuration names are usually written as dotted property names.

Value History

The appjar maintains a complete history of all previous values for each configuration entry. Saving a value never overwrites the one before it, so the history is a full record of how a configuration has evolved, including who changed it and when. An administrator or user can review past values and reuse any of them at any time, which makes rolling back a change straightforward.