How does FlexyPool support the Dropwizard Metrics package renaming

Last modified:

Are you struggling with performance issues in your Spring, Jakarta EE, or Java EE application?

What if there were a tool that could automatically detect what caused performance issues in your JPA and Hibernate data access layer?

Wouldn’t it be awesome to have such a tool to watch your application and prevent performance issues during development, long before they affect production systems?

Well, Hypersistence Optimizer is that tool! And it works with Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus, Micronaut, or Play Framework.

So, rather than fixing performance issues in your production system on a Saturday night, you are better off using Hypersistence Optimizer to help you prevent those issues so that you can spend your time on the things that you love!

Introduction

FlexyPool relies heavily on Dropwizard (previously Codahale) Metrics for monitoring the connection pool usage. Being integrated into Dropwizard, the package name was bound to be renamed.

So instead of com.codahale.metrics the 4.0.0 release will use the io.dropwizard.metrics package name.

The challenge

Apart from the obvious backward incompatibility, the most challenging aspect of this change is that the Maven dependency will only see a version incrementation. This means that you won’t be able to include both versions in the same Maven module, because the groupId and the artifactId will not change between the 3.x.x and the 4.x.x version change.

<dependency>
     <groupId>io.dropwizard.metrics</groupId>
     <artifactId>metrics-core</artifactId>
     <version>${codahale.metrics.version}</version>
</dependency>

<dependency>
     <groupId>io.dropwizard.metrics</groupId>
     <artifactId>metrics-core</artifactId>
     <version>${dropwizard.metrics.version}</version>
</dependency>

This change is manageable in an end-user application as you only have to migrate from one version to the other. An open source framework built on top of Dropwizard Metrics is much more difficult to refactor as you need to support two incompatible versions of the same library. After all, you don’t want to force your clients to migrate to a certain Metrics dependency.

Luckily, FlexyPool has had its own Metrics abstraction layer from the very beginning. Insulating a framework from external dependencies is a safety measure, allowing you to swap dependencies without much effort.

To support both Codahale and Dropwizard package names, FlexyPool metrics are build like this:

Because those classes cannot reside in one jar, there are three modules hosting this hierarchy:

flexy-pool-core: defines the FlexyPool Metrics abstraction
flexy-codahale-metrics: implements the FlexyPool metrics abstraction on top of Codahale Matrics
flexy-dropwizard-metrics: implements the FlexyPool metrics abstraction on top of Dropwizard Matrics

Each MetricsFactory is registered as a Service Provider:

public class CodahaleMetricsFactoryService 
    implements MetricsFactoryService {

    public static final String METRICS_CLASS_NAME = 
        "com.codahale.metrics.Metric";

    @Override
    public MetricsFactory load() {
        return ClassLoaderUtils
            .findClass(METRICS_CLASS_NAME) ? 
                CodahaleMetrics.FACTORY : null;
    }
}

public class DropwizardMetricsFactoryService 
    implements MetricsFactoryService {

    public static final String METRICS_CLASS_NAME = 
        "io.dropwizard.metrics.Metric";

    @Override
    public MetricsFactory load() {
        return ClassLoaderUtils
            .findClass(METRICS_CLASS_NAME) ? 
                DropwizardMetrics.FACTORY : null;
    }
}

and the services are resolved at runtime:

private ServiceLoader<MetricsFactoryService> 
    serviceLoader = ServiceLoader.load(
        MetricsFactoryService.class);

public MetricsFactory resolve() {
    for(MetricsFactoryService service : serviceLoader) {
        MetricsFactory metricsFactory = service.load();
        if(metricsFactory != null) {
            return metricsFactory;
        }
    }
    throw new IllegalStateException(
        "No MetricsFactory could be loaded!"
    );
}

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Conclusion

This way FlexyPool can use both Metrics implementations and the decision is taken dynamically based on the currently available library. The Dropwizard metrics 4.0.0 is not yet released, but FlexyPool is ready for the upcoming changes.

Follow @vlad_mihalcea