Why do you want to extend this?

We use multiple collector registries, and our servlet exports the samples from all of them. The same collector can appear in more than one registry.
If we simply concatenate the output of each registry, the result contains the TYPE and HELP headers more than once, which is not valid. To avoid this, the servlet maintains a set of the names of all the metrics that were already collected, and when it encounters one of the collected metrics it skips the headers and reports just the samples.
It seems to be working OK, but currently I have to duplicate all the code your TextFormat class. We would like to make it more extensible, so we can reuse your code.

Changing the exposition code is the wrong way to deal with that, the problem here is the way you're using the registry. You should have only one registry in standard usage.

We have standard metrics that are collected by all or our services. This works OK when each service is deployed independently. But we have few services deployed in the same web app and thus running in the same JVM. When they try to register the collector, they fail because the default registry is static and doesn't support multiple definitions of collectors with the same name. We overcome this by using a separate registry for each service, which is the same as what we have when each service is deployed independently.

It sounds like you might want to have a different endpoint per application, as you're basically a clustering system at that point.

If I understand correctly, you're suggesting to continue working with multiple registries, but to expose a different URL for scraping the samples from each registry? That is, instead of http://webapp/metrics that collects samples from all services, have something like http://webapp/metrics/serviceName for each service?

Yes.

But we have a generic monitor that sends the http://webapp/metrics request to all our servers, and doesn't know what's deployed on each server. Per your suggestion, the monitor would somehow need to know which service is deployed on each server, in order to construct all the proper URLs.

Per your suggestion, the monitor would somehow need to know which service is deployed on each server, in order to construct all the proper URLs.

Yes, that's standard when dealing with a cluster scheduler. Multiple independent apps inside on JVM is the same as multiple independent processes on a machine.

We have a generic metrics collector, shared by multiple projects.
Part of what it does is scanning machines in aws ec2 by various properties like their tags, and then collecting metrics in a somewhat generic way.
It doesn't really know what runs on every machine, and we prefer to keep it that way.

It sounds like what you've built is a monitoring system. The java client is not is intended to be used in that fashion, rather it feeds data into the Prometheus monitoring system.

I think you need to write a exporter to convert between your custom monitoring system and Prometheus.

What I described is our exported for prometheus. We don't want it to know every service and be required to update it for every new deployed service. This is also different in different deployment environments

What I described is our exported for prometheus.

You're attempting to implement a monitoring systems exporter as direct instrumentation, as you've discovered this does not work.

Fundamentally, you need to handle this before it hits a registry as this is something to be handled in a custom collector. There's no changes required in the exposition code.