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 safe 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!"
);
}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.
| Reference: | How does FlexyPool support the Dropwizard Metrics package renaming from our JCG partner Vlad Mihalcea at the Vlad Mihalcea’s Blog blog. |
