Convert environment variables to properties support
reedchan7 opened this issue · 4 comments
Generally, environment variables format are different from system properties format, for example: FOO_BAR
in environment variable and foo.bar
in property. My highest priority of load strategies is system:env
, so if I want to override a property I have to define an environment exactly equals to the property, which means foo.bar
in env and foo.bar
in property.
Now I want to define the env as FOO_BAR
not foo.bar
, could u support this feature? I think this would make the load strategy smarter :)
There is no any general specified format for system properties or environment variables names. You can use whatever you want, from what is accepted by e.g. your OS. Yes, java.lang.System
support set of "default" system properties in form "x.y.z" (e.g. java.version), but this is specific of this class, and not general & cross-platform rule.
So, I am personally, see this proposal as a very specific use case, which should not be supported in the library by default.
BUT. What you can do, is to implement you own loader, which is merge system:env & system:properties with renaming you wish. It's easy to do actually. Look at org.aeonbits.owner.loaders.Loader
interface & org.aeonbits.owner.Factory.registerLoader
method.
There is no any general specified format for system properties or environment variables names. You can use whatever you want, from what is accepted by e.g. your OS. Yes,
java.lang.System
support set of "default" system properties in form "x.y.z" (e.g. java.version), but this is specific of this class, and not general & cross-platform rule.So, I am personally, see this proposal as a very specific use case, which should not be supported in the library by default.
BUT. What you can do, is to implement you own loader, which is merge system:env & system:properties with renaming you wish. It's easy to do actually. Look at
org.aeonbits.owner.loaders.Loader
interface &org.aeonbits.owner.Factory.registerLoader
method.
@Gmugra OK, I got it. Thanks for your help, I'll try to implement my own loader. 🤔
My 50 cents: I haven't ever seen anyone used env variables in a format other than uppercase words separated with underscores. Moreover, I haven't seen any tools which use the other format for their env vars. Even Google suggests using this format in their style guide. That's why I was very surprised and confused to see that @Key
ignores my env variables specified in ENV_NAME
format.
@sskorol
I'm not quite sure what you mean by that.
e.g. this is working just fine:
@Sources("system:env")
public interface MyConfig extends Config {
@Key("JAVA_HOME")
String javaHome();
}
OWNER has no problem reading env variables with any name.
The problem @juan-chan encountered is about an exotic merging strategy between system:env and system:properties
FYI:
Unfortunately, OWNER is not really supported anymore.
@lviggiano multiple times wrote that he has no time for the project anymore.
New PRs are factually ignored.
So, there's not much point in waiting for new features. Unfortunately.
This OWNER situation has been a problem for me, so I've been developing an alternative with a similar API for some time now. Check it out. It might be more suitable for you. At least it in active developing and support.