SpringBoot Actuator env endpoint is not resilient with dashes

Version: springboot: 3.1 (don't think it is the point)

Let's declare two properties

my:
  properties:
    with-dashes: 1
    withoutDashes: 2

As documented, we can override properties values by sing environment. This part work well.

The problem is with actuator endpoint /actuator/env and /actuator/env/{toMatch}.

When I run my code with following environment variables MY_PROPERTIES_WITHDASHES=666 and MY_PROPERTIES_WITHOUTDASHES=777, on actuator I observe that without dashes, the endpoint /actuaor/env/my.properties.withoutDashes displays all sources of value, even the computed value

{
  "property": {
    "source": "systemEnvironment",
    "value": "777"
  },
  "activeProfiles": [],
  "propertySources": [
    {
      "name": "server.ports"
    },
    {
      "name": "systemProperties"
    },
    {
      "name": "systemEnvironment",
      "property": {
        "value": "777",
        "origin": "System Environment Property \"MY_PROPERTIES_WITHOUTDASHES\""
      }
    },
    {
      "name": "random"
    },
    {
      "name": "Config resource class path resource [application.yml] via location optional:classpath:/",
      "property": {
        "value": 2,
        "origin": "class path resource [application.yml] - 4:20"
      }
    },
    {
      "name": "Management Server"
    }
  ]
}

However, with the dashed property, I have /actuator/env/my.properties.with-dashes

{
  "property": {
    "source": "Config resource class path resource [application.yml] via location optional:classpath:/",
    "value": 1
  },
  "activeProfiles": [],
  "propertySources": [
    {
      "name": "server.ports"
    },
    {
      "name": "systemProperties"
    },
    {
      "name": "systemEnvironment"
    },
    {
      "name": "random"
    },
    {
      "name": "Config resource class path resource [application.yml] via location optional:classpath:/",
      "property": {
        "value": 1,
        "origin": "class path resource [application.yml] - 3:18"
      }
    },
    {
      "name": "Management Server"
    }
  ]
}

The value displayed contains neither the real value used by application (I exposed it with a controller which returns 666as expected) nor the reference of the environment variable.

The reference to the environment variable can be seen by requesting

/actuator/env/my.properties.withdashes (remove the dash)

{
  "property": {
    "source": "systemEnvironment",
    "value": "666"
  },
  "activeProfiles": [],
  "propertySources": [
    {
      "name": "server.ports"
    },
    {
      "name": "systemProperties"
    },
    {
      "name": "systemEnvironment",
      "property": {
        "value": "666",
        "origin": "System Environment Property \"MY_PROPERTIES_WITHDASHES\""
      }
    },
    {
      "name": "random"
    },
    {
      "name": "Config resource class path resource [application.yml] via location optional:classpath:/"
    },
    {
      "name": "Management Server"
    }
  ]
}

This behaviour can be quite troublesome, as it may lead to a misunderstanding of the real behaviour of an application. I can try to provide a fix if you confirm the unwilling behaviour.

I provided a sample project to display the behaviour.

Comment From: philwebb

The env endpoint here is actually working as designed and providing details about what values are returned when you make a call to Environment.getValue or use the @Value annotation.

The "Binding From Environment Variables" section is talking exclusively about @ConfigurationProperties binding, where additional logic is implemented to deal with the various different formats we support.

If you want to find out about what's actually been bound, the configprops endpoint is a better choice.

If you update the sample to expose the configprops endpoint and also set management.endpoint.configprops.show-values to always you can open http://localhost:8080/actuator/configprops/my.properties to see what is actually bound.

Your sample did highlight one problem: we're not currently displaying wrapper types correctly. I've opened #36076 to fix that.

Comment From: antechrestos

Thank you @philwebb