Externalized Properties was inspired by the The Twelve Factor Methodology's section III. Config.
The goal of this library is to make it easy for applications to implement configuration best practices by providing easy-to-use APIs as well as providing the flexibility to choose where to store their configurations/properties.
Externalized Properties takes full advantage of Java's Dynamic Proxies.
Why Dynamic Proxies?
* Dependency Injection Friendly
Since Externalized Properties works with interfaces, it makes it easy to integrate with dependency injection (DI) frameworks. it's as simple as building ExternalizedProperties, initializing a dynamic proxy from an interface, and registering the proxy interface to your chosen DI framework.
* Testing Friendly
Another side-effect of being dependency injection friendly is that it also makes it easy to mock/stub out configurations/properties on unit tests. It's as simple as creating a stub implementation of the proxy interface or using mocking frameworks to mock the proxy interface.
Reading section III, I see it specifically calls out the value in avoiding on-disk property files and named per-environment groupings of properties as non-scalable anti-patterns. I don't know whether or not I agree with that, but I am curious why you're claiming to be inspired by that section when, by and large, the only thing that seems to align with what's described in section III is not hardcoding the property values directly in code, which isn't really specific to the twelve factor methodology.
You can still strictly adhere to section III if you choose to - by only loading the environment variables, but Externalized Properties allows more than that if needed.
By using ExternalizedProperties instead of direct System.getenv() you get other useful features such as automatic conversions, variable expansion, and processing (e.g. automatic decryption/automatic base64 decode, etc)
I use PKL for most of my configuration needs these days. But PKL is only a format, it doesn't say where to store the config. Could I use Externalized Properties to e.g. fetch config from some random source but have it be PKL?
Definitely! There's no limit on what configuration formats Externalized Properties can support as you can implement custom `Resolver`s to retrieve from any source and format e.g.
public class PklResolver implements Resolver {
public Optional<String> resolve(InvocationContext context, String propertyName) {
return getFromPklConfig(propertyName);
}
}
// Register custom resolver when building ExternalizedProperties
ExternalizedProperties externalizedProperties = ExternalizedProperties.builder()
.resolvers(new PklResolver(...))
.build();
AppProperties appProperties = externalizedProperties.initialize(AppProperties.class);
// Resolves config from PklResolver
String myConfig = appProperties.myConfig();
It's more performant than other similar libraries such as the Owner and cfg4j which no longer seems to be actively developed at this point and others such as Spring's Environment and MicroProfile config implementations
Aside from the performance, the other advantage of using this config library is how it makes testing easier and how easy it is to integrate with your dependency injection frameworks of choice.
Externalized Properties was inspired by the The Twelve Factor Methodology's section III. Config.
The goal of this library is to make it easy for applications to implement configuration best practices by providing easy-to-use APIs as well as providing the flexibility to choose where to store their configurations/properties.
Externalized Properties takes full advantage of Java's Dynamic Proxies.
Why Dynamic Proxies?
* Dependency Injection Friendly
Since Externalized Properties works with interfaces, it makes it easy to integrate with dependency injection (DI) frameworks. it's as simple as building ExternalizedProperties, initializing a dynamic proxy from an interface, and registering the proxy interface to your chosen DI framework.
* Testing Friendly
Another side-effect of being dependency injection friendly is that it also makes it easy to mock/stub out configurations/properties on unit tests. It's as simple as creating a stub implementation of the proxy interface or using mocking frameworks to mock the proxy interface.
Reading section III, I see it specifically calls out the value in avoiding on-disk property files and named per-environment groupings of properties as non-scalable anti-patterns. I don't know whether or not I agree with that, but I am curious why you're claiming to be inspired by that section when, by and large, the only thing that seems to align with what's described in section III is not hardcoding the property values directly in code, which isn't really specific to the twelve factor methodology.
You can still strictly adhere to section III if you choose to - by only loading the environment variables, but Externalized Properties allows more than that if needed.
By using ExternalizedProperties instead of direct System.getenv() you get other useful features such as automatic conversions, variable expansion, and processing (e.g. automatic decryption/automatic base64 decode, etc)
I use PKL for most of my configuration needs these days. But PKL is only a format, it doesn't say where to store the config. Could I use Externalized Properties to e.g. fetch config from some random source but have it be PKL?
Definitely! There's no limit on what configuration formats Externalized Properties can support as you can implement custom `Resolver`s to retrieve from any source and format e.g.
How this compares with other libs and frameworks ?
It's more performant than other similar libraries such as the Owner and cfg4j which no longer seems to be actively developed at this point and others such as Spring's Environment and MicroProfile config implementations
See benchmarks here: https://github.com/joel-jeremy/java-config-library-benchmark...
Aside from the performance, the other advantage of using this config library is how it makes testing easier and how easy it is to integrate with your dependency injection frameworks of choice.