You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alpine's current Config API is very simplistic, which is fine for the majority of use cases.
While working on Hyades, we're encountering increasingly more situations where hierarchical and repeatable configs are required. For example, to configure multiple Kafka consumers, something like the following is done:
Creating redundant Config.Keys for each processor is impractical. Building a generic solution on top of this is possible, however it's complicated by the need to have values overwritable through multiple ways (i.e. application.properties and environment variables).
Further, we're finding that a mechanism to validate configuration on startup would be beneficial. As multiple subsystems are initialized one after another, users usually don't get to know about invalid configuration until the subsystem accessing it runs into an error.
I'm proposing to adopt a more capable config management solution, specifically MicroProfile Config.
SmallRye Config is currently the best / most maintained implementation of MicroProfile Config. It's used by Quarkus, but can be used without CDI (which is important since Alpine doesn't have it).
Applications based on Alpine can customize SmallRye Config to their needs, e.g. to add additional sources, or register ConfigMappings, using the SPI.
The introduction of SmallRye Config can be achieved in a backward compatible manner, where SR replaces the current Properties that back Alpine's Config class. Existing methods of Config can simply delegate to SR.
To gain direct access to SmallRyeConfig, we can expose it as delegate. For example, to access a ConfigMapping, users might do:
Alpine's current
Config
API is very simplistic, which is fine for the majority of use cases.While working on Hyades, we're encountering increasingly more situations where hierarchical and repeatable configs are required. For example, to configure multiple Kafka consumers, something like the following is done:
Creating redundant
Config.Key
s for each processor is impractical. Building a generic solution on top of this is possible, however it's complicated by the need to have values overwritable through multiple ways (i.e.application.properties
and environment variables).Further, we're finding that a mechanism to validate configuration on startup would be beneficial. As multiple subsystems are initialized one after another, users usually don't get to know about invalid configuration until the subsystem accessing it runs into an error.
I'm proposing to adopt a more capable config management solution, specifically MicroProfile Config.
SmallRye Config is currently the best / most maintained implementation of MicroProfile Config. It's used by Quarkus, but can be used without CDI (which is important since Alpine doesn't have it).
Applications based on Alpine can customize SmallRye Config to their needs, e.g. to add additional sources, or register
ConfigMapping
s, using the SPI.Another benefit is that SmallRye Config supports validation using standard bean validation annotations.
The introduction of SmallRye Config can be achieved in a backward compatible manner, where SR replaces the current
Properties
that back Alpine'sConfig
class. Existing methods ofConfig
can simply delegate to SR.To gain direct access to
SmallRyeConfig
, we can expose it as delegate. For example, to access aConfigMapping
, users might do:The text was updated successfully, but these errors were encountered: