Similar to this: https://github.com/spring-projects/spring-boot/issues/11864

STS team would like to start parsing the information in the 'env' actuator endpoint. Just a quick look at this it seems pretty straightforward, except for what is perhaps the most interesting part of it (from our point of view). I.e. the 'origin' field which gives a hint about where the property value came from.

For example:

management.endpoints.web.exposure.include[0]: {
value: "env",
origin: "class path resource [application.yml]:6:11"
}

Or: 

HOME: {
value: "/home/kdvolder",
origin: "System Environment Property "HOME""
}

It would be interesting to be able to offer some navigation support that helps user to open something like this in their IDE. So I suppose that means mainly the 'classpath resource' are of interest here.

So could we do something similar to what was done for handler methods? I.e. maybe something like this:

management.endpoints.web.exposure.include[0]: {
  value: "env",
  origin: "class path resource [application.yml]:6:11",
  details: {
    classpathResource: {
     path: "application.yml",
     line: 6,
     col: 11
    }
  }
}
}

I suppose we could probably try to parse the "origin" string with some 'string.indexOf('[') etc. But I'm not really keen on doing that if it can be avoided.

Comment From: philwebb

The Origin interface itself is pretty dumb, the only real contract is a toString() must be provided. The TextResourceOrigin subclass has got the information you need, but we can't say for sure that that will be the one in use. For example, you can also have a property picked up from a system environment variable.

Probably the best option would be to create some custom JSON output if the Origin is a TextResourceOrigin. We'll need to do that in a back compatible way.

Comment From: kdvolder

I think the situation is very similar to the 'handlerMethod' I linked above. I.e. there are potentially large (unbounded?) number of different things that could constitute a 'origin'. But we aren't necessarily interested in being able to parse all of them (well in theory we are, but in practice we just want to focus on some common cases for which we can do something meaningful, like.. open the associated text file and place the cursor in the right spot).

I think @wilkinsona had very similar concerns to the one's you are expressing. So he probably has some good ideas on how to approach it :-)

From my end this is what we want basically:

If the origin is from a properties/yaml file that we can open - then we should be able to recognise easily this is the case - and we should be able to easily/reliably parse its details and extract the info needed/sufficient to open the file.

If the origin is something else... then we don't care. (Maybe in the future we might, if can come up with something meaningful to do with the information, but that would be a totally separate/new issue then).