SpringBoot Exposing the env var equivalent of a property name in the Configuration Metadata

Hello. Spring newbie here.

First of all, congrats on spring-boot-configuration-processor - it's a neat idea, and I use that a lot.

As we know, Spring (Boot only?) allows for env vars to be used in its properties:

# run with SOME_COOL_PROPERTY=dummy2
my.cool.property = ${SOME_COOL_PROPERTY:dummy}

My current problem is that, from what I've witnessed, people are explicitly putting env vars in *.properties files, like in the above snippet, when they can actually just use the env var:

# run with MY_COOL_PROPERTY=dummy2
my.cool.property = dummy

I imagine they do this because they prefer that explicitness. I don't think the name conversion process is known enough. This is where the Automatic Metadata Generation comes in.

I was wondering if the Configuration Metadata could be augmented to include the equivalent env var, so people will at least know how Spring converts these property names - which sometimes can surprise. I'm hoping that this will build enough trust, that they'll actually start using metadata more, and that they'll sometimes avoid adding explicit env vars unnecessarily.

It could be something like this:

{"properties": [
  {
    "name": "acme.messaging.addresses",
    "defaultValue": ["a", "b"],
    "envVarName": "ACME_MESSAGING_ADDRESSES"
  },
  {
    "name": "acme.messaging.container-type",
    "defaultValue": "simple",
    "envVarName": "ACME_MESSAGING_CONTAINER_TYPE"
  }
]}

I'm not sure if this is a solution to my problem. I'm not even convinced it's a real problem. My thinking is that more metadata can't hurt.

Thanks for tuning in.

Comment From: snicoll

Thanks for the suggestion but the way a property can be bound based on the canonical format is already documented in the reference guide. Given that the env var name mapping can be inferred based on the documentation, I don't think shipping that in the metadata would help there as it would be quite redundant.