Skip to content

Retain and expose managed export metadata#71

Open
dain wants to merge 1 commit into
martint:masterfrom
dain:user/dain/managed-object-export-metadata
Open

Retain and expose managed export metadata#71
dain wants to merge 1 commit into
martint:masterfrom
dain:user/dain/managed-object-export-metadata

Conversation

@dain

@dain dain commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

Why

  • Systems such as OpenMetrics and OpenTelemetry have their own metric naming conventions and need the original export intent to build useful names.
  • Today, jmxutils collapses the Java type and generated-name inputs into a final ObjectName, which forces consumers to reverse-engineer naming intent from JMX properties.
  • Consumers still need the final ObjectName because configured generators may rewrite domains or add identity properties used as labels.

Approach

  • Add a managed export descriptor keyed by final ObjectName.
  • Retain the original Java type, generated-name argument, generated-properties map, and associated ManagedClass when available.
  • Keep the existing getManagedClasses() API as a compatibility projection.

Systems such as OpenMetrics and OpenTelemetry have their own metric
naming conventions. They need the original Java type and generated-name
inputs to build those names, while still using the final ObjectName for
identity and labels.

ObjectNameGenerator collapses that context into a final ObjectName, so
consumers otherwise have to reverse-engineer naming intent from JMX
properties. Retain the export metadata beside ManagedClass to make that
intent available directly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant