FlexyPool如何支持Dropwizard Metrics包重命名

介绍

FlexyPool严重依赖Dropwizard （以前是Codahale）度量标准来监视连接池的使用情况。集成到Dropwizard中后，程序包名称必然会被重命名。

因此，4.0.0版本将使用io.dropwizard.metrics软件包名称代替com.codahale.metrics 。

挑战

除了明显的向后不兼容之外，此更改最具有挑战性的方面是Maven依赖项只会看到版本递增。这意味着您将无法在同一Maven模块中包含两个版本，因为groupId和artifactId在3.xx和4.xx版本之间不会更改。

<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>

在最终用户应用程序中，此更改是可管理的，因为您只需要从一个版本迁移到另一个版本即可。由于需要支持同一库的两个不兼容版本，因此基于Dropwizard指标构建的开放源代码框架很难重构。毕竟，您不想强迫您的客户端迁移到某个Metrics依赖项。

幸运的是，FlexyPool从一开始就拥有自己的Metrics抽象层。将框架与外部依赖项隔离是一种安全的措施，使您无需费力即可交换依赖项。

为了同时支持Codahale和Dropwizard软件包名称，FlexyPool指标的构建如下：

柔性比重计分法

由于这些类不能驻留在一个jar中，因此有三个模块承载此层次结构：

flexy-pool-core：定义FlexyPool指标抽象
flexy-codahale-metrics：在Codahale矩阵的顶部实现FlexyPool指标抽象
flexy-dropwizard-metrics：在Dropwizard矩阵之上实现FlexyPool指标抽象

每个MetricsFactory均已注册为服务提供商：

public class CodahaleMetricsFactoryService implements MetricsFactoryService {public static final String METRICS_CLASS_NAME = "com.codahale.metrics.Metric";@Overridepublic 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";@Overridepublic MetricsFactory load() {return ClassLoaderUtils.findClass(METRICS_CLASS_NAME) ? DropwizardMetrics.FACTORY : null;}
}

并在运行时解析服务：

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!");
}