标签：row 不兼容 问题 dde img for cat 反射 IV
来自于最近的一个实际场景中.
某个应用的依赖A依赖了B,应用A也直接依赖了B.(简化处理,实际情况还有几层)
如下:
也是现实中比较常见的一个依赖关系.
但有一个问题,应用和A用的B版本不一致,且使用的版本不兼容.
不兼容体现在包名发生了变更,新的B的包名被改了,之前的spring配置需要更改才能对新的B有效.
这样的依赖关系倒逼着应用升级,不升级会导致依赖A在运行期出现各种符号找不到的错误.(直接依赖覆盖间接依赖)
但在升级过程中发现新的依赖去除了一些功能使得在当前应用里无法正常工作.
不过运气好的是老依赖的实现在A中可以正常工作.
总结一下
新的B在应用中无法工作,只能使用老版本里的B,A可以兼容新老的B.(那为什么不把A依赖的B降回去?那是因为其他一些应用已经接了并且升级...)
那如何处理呢?
通过一些讨论和思考,这样的依赖应该被切断,A不能依赖B.
那A如何工作,答案就是使用反射.
A这样依赖外部提供的B(其实和maven的provide scope类似,但这里的问题是高低版本兼容....).
并且A根据不同的B调用不同的方法.
A中代码改动如下:
@PostConstruct
public void init() throws ClassNotFoundException, NoSuchMethodException, SecurityException {
Class clazz = null;
try {
clazz = Class.forName("com.b.package1");
} catch (ClassNotFoundException e) {
LOG.error("init - com.b.package1 failed", e);
}
if (clazz == null) {
try {
clazz = Class.forName("com.b.package2");
} catch (ClassNotFoundException e) {
LOG.error("init - com.b.package2 failed", e);
}
}
if (clazz == null) {
throw new ClassNotFoundException("dependency not found. please add b ");
}
usedMethod= clazz.getMethod("methodName");
bean= applicationContext.getBean("beanName", clazz);
if (bean== null) {
throw new UnsatisfiedDependencyException(this.getClass().getName(), "beanName",
"bean", "failed to init");
}
}ps:当前问题因为记录需要被简化了,实际中A作为一个偏底层的依赖去直接依赖应用方直接使用的B本身是不合理的,这个做法纯粹是为了解决眼下的兼容性问题.
其次在日常升级中,实现不兼容,方法签名变更等升级大版本号之类就足够了,但如果整个依赖的基础包名都改了的话,最好还是修改artifactId吧.... ...
标签：row 不兼容 问题 dde img for cat 反射 IV
原文地址：https://www.cnblogs.com/fairjm/p/9209258.html
