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
I couldn't find any documentation reference for including JVM properties and good old environment variables as configuration source. Due to the popularization of Docker philosophy and 12-factor application concept it would be quite nice to provide library users with simple way to use both sources in their apps. I've already found a workaround with InMemoryConfigurationSource (and i know that documentation will become confusing the very moment it will specify word 'environment' in two meanings), however, i feel that is necessary to update library in that way (or at least mention InMemoryConfigurationSource workaround in documentation).
The text was updated successfully, but these errors were encountered:
This would be super helpful to have, since it would allow for easy integration with 12 Factor Application Configuration conventions. For the EnvironmentVariableSource it would make sense for the Environment to define the prefixed namespace for the Environment Variables that you are interested in.
For example if you had and application name foo, with configurable properties bar and baz, you would format your environment in the following manner:
Thus if you have the Environment context set to FOO then I would expect the EnvironmentVariableSource would only return: BAR and BAZ along with their corresponding value.
Let me know what you think. I wouldn't mind working on implementing this feature since, selfishly, this would be very useful for what I need to do. I am looking into using envconsul to insert the config from Consul and Environment variables, instead of using the ConsulConfigurationSource. I figured this will be much more flexible since we have applications not running on a JVM (like nodeJS) and this would provide a more consistent way to configure applications from Consul. And I could then use cfg4j to implement loading the configuration from Environment Variables and overlaying it with local config files etc nicely for our JVM based applications. Other non JVM applications will have to use a different library of course, but the means for retrieving the configuration will be more consistent this way :)