Other Configuration Solutions

There are several alternative solutions to application configuration. Many address different issues than AndHow. Others don't solve configuration quite as nicely.

Spring

Spring has an implicit application strategy in which most needed classes are created at startup. This helps toward the goal of failing fast for invalid configuration, but it is up to the constructed classes to do type conversions and validate their configuration. Documentation for application configuration is thus buried in the validation code of Spring bean class.

Spring will read properties found in its application.properties file and make those values available in xml files via EL like ${my.property.value}. System properties and environment variables use EL in the form #{systemProperties['APP.LOG_PATH']} and #{systemEnvironment['HOME']} respectively. All of these assume you know (or care) where specific property values are to be loaded from. SpringBoot has additional options which are an improvement and might be a realistic alternative to AndHow for applications that use it.

JNDI

JNDI provides a Java standard way to configure an app, but doesn’t have a built-in way to include other configuration sources, such as environment variables and system properties. JNDI is a typed system, but doesn’t do validation. Since code using JNDI tends to pull configuration on demand, it tends towards a fail late design, where missing or invalid configuration is not known until it is encountered.

To application code, JNDI presents as an Object hash map. Retrieving values requires using 'magic key strings' sprinkled in your code and casting the returned value to a specific type. Short of a complete, correct and well commented application context file w/ JNDI properties, there is no central documentation.

Commons Configuration

An Apache project that loads properties from many sources, like AndHow. It is a well established and active project with some features that AndHow does not have, including multi-value properties and updatable properties.

The two project have fundamentally different approaches, however. In AndHow, all Properties are declared with a type and (optionally) can be given validation and marked as required. If a property is missing or given an invalid value, the application will throw a RuntimeError at startup, thus failing fast. In Commons Config, Configuration objects load the properties they find from various sources. Since the properties are not declared, there is no defined type or validation possible, resulting in a fail late design. Commons Config's lack of property declaration and multiple property sources means that configuration documentation is difficult and not helped by the configuration framework.

To application code, Commons Config presents similar to JDBC with 'magic strings' used to specify the value you want to read. Properties can be fetch by type, as in: config.getInt(“property.name”); //similar to fetching value from JDBC but that conversion will fail at the time it is encountered, not at startup.

DROP - A USGS configuration tool

DROP reads from system properties, JNDI and properties files. It does not distinguish between null values and an uninitiated system. It also doesn’t complain if it is initiated multiple times. All DROP values are untyped (strings) with no validation.