Clint Checketts

The Consul API returns a payload like so: ``` [ { "node": "promregator-url.org", "datacenter": "cfapi", "taggedAddresses": {}, //Not used "nodeMeta": {}, //Not used "serviceAddress": "promregator-url.org", "serviceId": "e287be8c-b6ad-4fbc-af13-ae9f322310a9", //CF App ID...

> In short, I am totally in line to expose more information via the consul's metadata structure, but I am a little hesitant on getting rid of the target's configuration...

Renaming this issue since consul discovery is no longer needed now that [HTTP discovery](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#http_sd_config) exists as a first class citizen in Prometheus.

Yes and No. ;) As in the v2 endpoint I propose in #208 it should just passthrough the Prometheus call to the underlying service. So if that service exposed OpenMetrics,...

I believe @maorelias Is correct. @ivarconr when different threads in java are accessing a variable that could change, there is chance that a thread could read a stale (cached) value....

Feel free to assign the issue to me. I have another PR I'll be working on soon. (Unless @maorelias wants to tackle this)

@thombergs That sounds like we won't be able to support both Spring 5 and Spring 6 at the same time. Right?

Heads up the the `spring.factories` config changed in Spring 3: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0.0-M5-Release-Notes#auto-configuration-registration

I'll be working with a company that uses AppDynamics shortly and should be able to dig into this.

Yes. So I'm finally actually to the point of working on it. Here are my findings: - The recommended extension mechanism relies on extending a base class, but the dependency...