Metrics

The .addMetrics() builder call wires Dropwizard Metrics into the proxy. Every method invocation is timed and recorded against a Dropwizard Timer keyed by the method signature.

Basic usage

Service proxy = DynamicProxyBuilder
    .createBuilder(Service.class, new ServiceImpl())
    .addMetrics()
    .build();

That is the entire setup. From this point on, every call to the proxy is measured.

Where the metrics live

Timings are collected through RapidPMMetricsRegistry, a thin wrapper over a Dropwizard MetricRegistry. You can:

• Read the registry programmatically for assertions in tests.
• Hook up a JmxReporter to expose timings through JMX.
• Hook up a ConsoleReporter for development.

The metrics-jmx dependency is intentionally kept on the project so that JMX-based reporting works out of the box.

What is recorded

For each invocation on the proxy:

• A timer is started before the real method runs.
• The timer stops in the post-action, after the real method returns or throws.
• The recorded duration covers the real implementation plus any pre-actions and post-actions registered between addMetrics() and the real call.

If you want to measure only the implementation, register addMetrics() last in the builder chain.

Naming

Metric names are derived from the method signature so that overloads are distinguishable. Inspect the registry to see the exact names used in your classpath.

Combining with security and logging

addMetrics() composes cleanly with the other builder features:

Service proxy = DynamicProxyBuilder
    .createBuilder(Service.class, new ServiceImpl())
    .addSecurityRule(() -> currentUserCanCallService())
    .addLogging()
    .addMetrics()
    .build();

Refused calls (blocked by a security rule) do not advance the metric timer — the timer is only entered for invocations that pass the security checks.

Compile-time equivalent

For the same behaviour without runtime reflection, see @StaticMetricsProxy.