Consider changing the output of /application/env/{propertyName}

[snicoll]

The endpoint that provides information about a single property looks like this now (for the JAVA_VERSION system property:

{
  "activeProfiles": [
    
  ],
  "propertySources": [
    {
      "name": "server.ports",
      "properties": {
        
      }
    },
    {
      "name": "servletContextInitParams",
      "properties": {
        
      }
    },
    {
      "name": "systemProperties",
      "properties": {
        "java.version": {
          "value": "1.8.0_121",
          "origin": null
        }
      }
    },
    {
      "name": "systemEnvironment",
      "properties": {
        
      }
    },
    {
      "name": "applicationConfig: [classpath:/application.properties]",
      "properties": {
        
      }
    }
  ]
}

I like the fact that the output is a bit more consistent with the main endpoint but:

1. I'd like that we add a value root attribute with the actual value in the environment. Previously that's all we had and this information is lost. IMO, it's quite interesting to have the actual value without computing it from the first property source in the list
2. I don't think that showing empty property sources are very interesting. I do think that showing in the output that this particular key has many source is super interesting but the fact it's not present in one is noise

[wilkinsona]

I'd like that we add a value root attribute with the actual value in the environment

This sounds like a good addition to me

I don't think that showing empty property sources are very interesting. I do think that showing in the output that this particular key has many source is super interesting but the fact it's not present in one is noise

If you're using the endpoint to check the value of a property and figure out why it has that value, seeing information about all of the property sources is useful. If property sources that do not contain the property are omitted you can't tell if that source was missing (e.g. your application.properties file wasn't picked up) or if you messed up configuring the property in that source. In short, I disagree that a property not being present in a property source is noise.

We could, perhaps, convey the same information more concisely. We could list all of the sources where the property was found, including the origin information. The sources that exist but don't contain the property could then be listed separately. This suggestion has two downsides:

1. The format of the propertySources entry would differ from the main /application/env endpoint
2. We'd lose some information about the ordering of all the sources

1 isn't so bad, but 2 makes the endpoint less useful as it no longer tells you which sources you could add a property to if you wanted to override the value of the property that's coming from a particular source.

In summary, I am in favour of adding the value of the specific property to the response in a separate entry in the map. I am not in favour of changing the property sources that are included in the response.

[snicoll]

That makes sense to me, thanks.

[snicoll]

We should also consider skipping the origin rather than adding it with null

[snicoll]

So we've settled for this

{
  "property": {
    "value": "1.8.0_121",
    "source": "systemProperties"
  },
  "activeProfiles": [
    
  ],
  "propertySources": [
    {
      "name": "server.ports",
      "property": {
        
      }
    },
    {
      "name": "servletContextInitParams",
      "property": {
        
      }
    },
    {
      "name": "systemProperties",
      "property": {
        "value": "1.8.0_121",
        "origin": null
      }
    },
    {
      "name": "systemEnvironment",
      "property": {
        
      }
    },
    {
      "name": "applicationConfig: [classpath:/application.properties]",
      "property": {
        
      }
    }
  ]
}