paulschwarz/spring-dotenv

Support relaxed bindings for acting like SystemEnvironmentPropertySource

glandais opened this issue · 2 comments

glandais commented

This will allow to use variable with an indirection in Spring properties

natrem commented

@paulschwarz I'm willing to give it a try.

One important note when comparing SystemEnvironmentPropertySource with the official documentation is that SystemEnvironmentPropertySource supports for namings.

For instance, based on the doc, my-app.component.long-property should map to environment MYAPP_COMPONENT_LONGPROPERTY

Based on the implementation (which is straightforward to replicate with tests), you would support

  • my-app.component.long-property
  • my-app_component_long-property
  • my_app.component.long_property
  • my_app_component_long_property
  • MY-APP.COMPONENT.LONG-PROPERTY
  • MY-APP_COMPONENT_LONG-PROPERTY
  • MY_APP.COMPONENT.LONG_PROPERTY
  • MY_APP_COMPONENT_LONG_PROPERTY
    but not the documented pattern.

It would be quite easy to look for the MYAPP_COMPONENT_LONGPROPERTY only.

Considering readability (and easiness to replicate spring code), I suggest to tolerate:

  • either all the patterns in SystemEnvironmentPropertySource + the documented standard
  • or the documented standard + default version (no transformation for compatibility) + all underscores (latest version, for readability)

Do you have a preference?

note1: I made a quick and dirty wrap around your library and it works fine for a simple case.
note 2: looking for documented name in spring boot for system properties is done through class SpringConfigurationPropertySource