My main motivation to extend theMicrometerMetrics class is to avoid using a delegate pattern. This is how we've implemented this right now:

publicclassCustomResourceMetricsimplementsMetrics {privatefinal@NotNullMetricsdelegate;@OverridepublicvoidcontrollerRegistered(final@NotNullController<?extendsHasMetadata>controller) {delegate.controllerRegistered(controller);    ...  }@OverridepublicvoidreconcileCustomResource(final@NotNullHasMetadataresource,final@NotNullRetryInforetryInfo,final@NotNullMap<String,Object>metadata) {delegate.reconcileCustomResource(resource,retryInfo,metadata);  }}

This works fine, but we need to implement all methods ofMetrics to preserve the JOSDK provided metrics. And if there would ever be a new default method inMetrics that is implemented inMicrometerMetrics, it would silently break something.

An alternative approach would be to allow multipleMetrics implementations. Then we could just configure theMicrometerMetrics as they are and our custom metrics together. But this might actually break public APIs, especially the getter signatures:

publicclassConfigurationServiceOverrider {privateList<Metrics>metrics;publicConfigurationServiceOverriderwithMetrics(Metricsmetrics) {returnwithMetrics(List.of(metrics));  }publicConfigurationServiceOverriderwithMetrics(List<Metrics>metrics) {this.metrics =metrics;returnthis;  }publicConfigurationServicebuild() {returnnewBaseConfigurationService(original.getVersion(),cloner,client) {@OverridepublicList<Metrics>getMetrics() {returnmetrics !=null ?metrics :original.getMetrics();      }   }}

publicinterfaceConfigurationService {defaultList<Metrics>getMetrics() {returnList.of(Metrics.NOOP);  }}

An alternative approach would be to allow multipleMetrics implementations. Then we could just configure theMicrometerMetrics as they are and our custom metrics together. But this might actually break public APIs, especially the getter signatures:

publicclassConfigurationServiceOverrider {privateList<Metrics>metrics;publicConfigurationServiceOverriderwithMetrics(Metricsmetrics) {returnwithMetrics(List.of(metrics));  }publicConfigurationServiceOverriderwithMetrics(List<Metrics>metrics) {this.metrics =metrics;returnthis;  }publicConfigurationServicebuild() {returnnewBaseConfigurationService(original.getVersion(),cloner,client) {@OverridepublicList<Metrics>getMetrics() {returnmetrics !=null ?metrics :original.getMetrics();      }   }}

publicinterfaceConfigurationService {defaultList<Metrics>getMetrics() {returnList.of(Metrics.NOOP);  }}

Alternatively, one could implement an aggregateMetrics implementation that would allow to register multipleMetrics implementations and would then dispatch to all registered implementations for each method call. This would be similar to the delegate pattern I guess but a little bit more flexible.

For that matter, such an aggregate implementation could even be provided by JOSDK.

Alternatively, one could implement an aggregateMetrics implementation that would allow to register multipleMetrics implementations and would then dispatch to all registered implementations for each method call. This would be similar to the delegate pattern I guess but a little bit more flexible.

I think that might actually be the smartest approach with the least impact to the existing classes and APIs! I'm happy to rewrite this PR or create an alternative one with that approach.

Alternatively, one could implement an aggregateMetrics implementation that would allow to register multipleMetrics implementations and would then dispatch to all registered implementations for each method call. This would be similar to the delegate pattern I guess but a little bit more flexible.

I think that might actually be the smartest approach with the least impact to the existing classes and APIs! I'm happy to rewrite this PR or create an alternative one with that approach.

Whatever you think is more appropriate but I do think that this approach would be better, indeed. What do you think@csviri,@xstefank?