一种解决jar包冲突的组件实现

对于java开发程序员来说,jar包冲突是个让人很头痛的问题,而osgi可以解决这个问题,但是使用成本比较高,必须要按照osgi那一套结构来才能使用,在现有项目代码基础上重构的成本比较高,因此我通过学习osgi那一套实现,设计了一款使用不依赖osgi且使用门槛比较低的解决jar包冲突的组件,但没有在生产环境验证过,只是用来学习而已,代码见https://github.com/zjuphoenix/container-parent 。

其基本设计思想是把系统中依赖的组件全都单独打成一个bundle,比如项目依赖了几个单独的模块bundle1、bundle2等等,而bundle1和bundle2都依赖了netty,project本身也依赖了netty,但我们想要bundle1、bundle2和应用他们分别使用自己独立的netty版本的依赖,应用业务也用自己独立的netty版本。这时需要为bundle1和bundle2设计单独的自定义classloader,用于加载该bundle自己的类和依赖的第三方库。

首先看下测试项目打成的test.tar.gz压缩包解压后的目录结构:

一种解决jar包冲突的组件实现_第1张图片
test project dir.png

测试项目中除了包含lib(依赖的第三方库)和bin(运行脚本文件存放位置)这两个目录,还包含一个container目录,里面包含bundle-first和bundle-second两个依赖的模块和一个lib(conatiner自己的类及依赖),每个模块的目录结构包含一个lib目录(用于存放该模块自身类的jar包和依赖的第三方jar包)和一个config.json配置文件(用于定义该模块要暴露给业务方使用的类和需要从业务方类库中导入的类)

假设应用依赖了两个组件bundle1和bundle2,且希望这两个组件的类与应用自己的类隔离开来,其classloader隔离实现原理如下图:

一种解决jar包冲突的组件实现_第2张图片
classloader隔离实现架构.png

下面以测试项目test为例阐述class隔离实现,首先test项目依赖了bundle-first和bundle-second这两个组件,bundle-first依赖了netty的4.1.8版本,bundle-second依赖了netty的4.1.7版本,并且他们都依赖了spring的4.3.7版本,test自己也依赖了netty的4.1.6版本,假设希望这两个组件分别使用自己的netty版本,但希望使用应用依赖的spring版本,因此需要在配置文件中设置如下,以bundle-first为例:

{
  "exportJars":["bundle-first-api-1.0.jar", "bundle-first-1.0.jar"],
  "importPackages":["org.springframework", "com.study.bundle.first.api"]
}

以bundle-first为例,需要把自己的api包和实现包暴露出去,bundle-first-api-1.0.jar包中的类为BundleFirstApi接口,bundle-first-1.0.jar实现包中的类是BundleFirstImpl(BundleFirstApi接口实现),需要设置spring的依赖为import,表示spring的类不用bundle-first自己的classloader加载,交给应用类加载器去加载,需要注意的是必须要将bundle-first-api-1.0.jar中的接口类所在的包名作为import设置,让应用类加载器来加载这个api接口类,否则该接口类会由bundle-first的classloader加载,而在应用中获取该接口类BundleFirstApi实例的时候该接口类又会被应用类加载器加载一次,这样接口类实现类BundleFirstImpl与应用类加载器加载的BundleFirstApi类不属于父子关系,因为BundleFirstImpl的父类是由bundle-first的classloader加载的BundleFirstApi,不是应用类加载器加载的BundleFirstApi,从而无法强转而出现ClassCastException,如果把BundleFirstApi作为import配置在配置文件中,当加载BundleFirstImpl类时会先加载BundleFirstApi,当发现该类是import配置时,会交由应用类加载器该类,这样bundle-first的classloader加载的BundleFirstImpl类与应用类加载器加载的BundleFirstApi类便构成了父子关系。

从应用的lib包中可以看到,应用类依赖了bundle-first-api-1.0.jar和bundle-second-api-1.0.jar这两个组件的api包,应用通过ServiceLoader机制获取组件的实例,且通过ContainerClassLoader类加载器加载。

对该jar包隔离组件的用法是:首先要对要依赖的组件的api进行抽离,然后把实现类是api的包分为两个不同的包,如bundle-first-api-1.0.jar和bundle-first-1.0.jar。bundle-first-api-1.0.jar是要让应用在maven pom里去显示依赖的包,bundle-first-1.0.jar不需要显示依赖。这样实际上该组件依赖的第三方依赖如netty都会在bundle-first-1.0.jar依赖里,而没有在bundle-first-api-1.0.jar的依赖里,应用只依赖了bundle-first-api-1.0.jar,所以bundle-first的第三方依赖包不会引入到应用的依赖中,应用只是用到了bundle-first-api-1.0.jar这个包而已。

下面根据上图逐步分析:

  • step1:应用要加载BundleFirstApi类,因为应用的classpath中也有bundle-first-api-1.0.jar,因此也可以加载到BundleFirstApi类。
  • step2:应用通过ContainerClassLoader类加载器加载BundleFirstImpl组件实现类。
  • step3:ContainerClassLoader会判断BundleFirstImpl类是不是export class中的类,是的话便交给BundleExportClassManager处理。
  • step4:BundleExportClassManager维护着所有export class的缓存,在容器启动过程中就会把每个bundle的classloader创建好并根据配置文件把export class全都用相应的BundleClassLoader加载出来放在缓存中(注意:当加载暴露的类中的api接口实现类时,以BundleFirstImpl为例,要先加载其父类BundleFirstApi,因为BundleFirstApi是import类,会交给应用类加载器加载,也就是父类和子类不是同一个classloader加载的),因此可以根据类的全限定名从BundleExportClassManager获取每个bundle暴露出来的类,ContainerClassLoader把要加载的bundle-first的实现类的全限定名交给BundleExportClassManager,BundleExportClassManager找到对应的组件实现类并实例化。
  • step5:得到组件实现类BundleFirstImpl实例后,便可以调用该组件的一些方法了。

测试结果如下:

App:
test spring classloader:sun.misc.Launcher$AppClassLoader@14dad5dc
spring version: 4.3.6.RELEASE
test app class: io.netty.util.Version classloader:sun.misc.Launcher$AppClassLoader@14dad5dc
app netty version:{netty-buffer=netty-buffer-4.1.6.Final.35fb0ba, netty-codec=netty-codec-4.1.6.Final.35fb0ba, netty-codec-dns=netty-codec-dns-4.1.6.Final.35fb0ba, netty-codec-haproxy=netty-codec-haproxy-4.1.6.Final.35fb0ba, netty-codec-http=netty-codec-http-4.1.6.Final.35fb0ba, netty-codec-http2=netty-codec-http2-4.1.6.Final.35fb0ba, netty-codec-memcache=netty-codec-memcache-4.1.6.Final.35fb0ba, netty-codec-mqtt=netty-codec-mqtt-4.1.6.Final.35fb0ba, netty-codec-redis=netty-codec-redis-4.1.6.Final.35fb0ba, netty-codec-socks=netty-codec-socks-4.1.6.Final.35fb0ba, netty-codec-stomp=netty-codec-stomp-4.1.6.Final.35fb0ba, netty-common=netty-common-4.1.6.Final.35fb0ba, netty-handler=netty-handler-4.1.6.Final.35fb0ba, netty-handler-proxy=netty-handler-proxy-4.1.6.Final.35fb0ba, netty-resolver=netty-resolver-4.1.6.Final.35fb0ba, netty-resolver-dns=netty-resolver-dns-4.1.6.Final.35fb0ba, netty-tcnative=netty-tcnative-1.1.33.Fork23.f89906a, netty-transport=netty-transport-4.1.6.Final.35fb0ba, netty-transport-native-epoll=netty-transport-native-epoll-4.1.6.Final.35fb0ba, netty-transport-rxtx=netty-transport-rxtx-4.1.6.Final.35fb0ba, netty-transport-sctp=netty-transport-sctp-4.1.6.Final.35fb0ba, netty-transport-udt=netty-transport-udt-4.1.6.Final.35fb0ba}
BundleFirst:
test import: spring classloader:sun.misc.Launcher$AppClassLoader@14dad5dc
spring version: 4.3.6.RELEASE
test import: BundleFirstApi classloader:sun.misc.Launcher$AppClassLoader@14dad5dc
test export: BundleFirstImpl classloader:bundle-first's BundleClassLoader
test bundle class: io.netty.util.Version classloader:bundle-first's BundleClassLoader
bundle-first netty version:{netty-buffer=netty-buffer-4.1.8.Final.76e22e6, netty-codec=netty-codec-4.1.8.Final.76e22e6, netty-codec-dns=netty-codec-dns-4.1.8.Final.76e22e6, netty-codec-haproxy=netty-codec-haproxy-4.1.8.Final.76e22e6, netty-codec-http=netty-codec-http-4.1.8.Final.76e22e6, netty-codec-http2=netty-codec-http2-4.1.8.Final.76e22e6, netty-codec-memcache=netty-codec-memcache-4.1.8.Final.76e22e6, netty-codec-mqtt=netty-codec-mqtt-4.1.8.Final.76e22e6, netty-codec-redis=netty-codec-redis-4.1.8.Final.76e22e6, netty-codec-smtp=netty-codec-smtp-4.1.8.Final.76e22e6, netty-codec-socks=netty-codec-socks-4.1.8.Final.76e22e6, netty-codec-stomp=netty-codec-stomp-4.1.8.Final.76e22e6, netty-common=netty-common-4.1.8.Final.76e22e6, netty-handler=netty-handler-4.1.8.Final.76e22e6, netty-handler-proxy=netty-handler-proxy-4.1.8.Final.76e22e6, netty-resolver=netty-resolver-4.1.8.Final.76e22e6, netty-resolver-dns=netty-resolver-dns-4.1.8.Final.76e22e6, netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb, netty-transport=netty-transport-4.1.8.Final.76e22e6, netty-transport-native-epoll=netty-transport-native-epoll-4.1.8.Final.76e22e6, netty-transport-rxtx=netty-transport-rxtx-4.1.8.Final.76e22e6, netty-transport-sctp=netty-transport-sctp-4.1.8.Final.76e22e6, netty-transport-udt=netty-transport-udt-4.1.8.Final.76e22e6}
1
BundleSecond:
test import: spring classloader:sun.misc.Launcher$AppClassLoader@14dad5dc
spring version: 4.3.6.RELEASE
test import: BundleSecondApi classloader:sun.misc.Launcher$AppClassLoader@14dad5dc
test export: BundleSecondImpl classloader:bundle-second's BundleClassLoader
test bundle class: io.netty.util.Version classloader:bundle-second's BundleClassLoader
bundle-second netty version:{netty-buffer=netty-buffer-4.1.7.Final.7a21eb1, netty-codec=netty-codec-4.1.7.Final.7a21eb1, netty-codec-dns=netty-codec-dns-4.1.7.Final.7a21eb1, netty-codec-haproxy=netty-codec-haproxy-4.1.7.Final.7a21eb1, netty-codec-http=netty-codec-http-4.1.7.Final.7a21eb1, netty-codec-http2=netty-codec-http2-4.1.7.Final.7a21eb1, netty-codec-memcache=netty-codec-memcache-4.1.7.Final.7a21eb1, netty-codec-mqtt=netty-codec-mqtt-4.1.7.Final.7a21eb1, netty-codec-redis=netty-codec-redis-4.1.7.Final.7a21eb1, netty-codec-smtp=netty-codec-smtp-4.1.7.Final.7a21eb1, netty-codec-socks=netty-codec-socks-4.1.7.Final.7a21eb1, netty-codec-stomp=netty-codec-stomp-4.1.7.Final.7a21eb1, netty-common=netty-common-4.1.7.Final.7a21eb1, netty-handler=netty-handler-4.1.7.Final.7a21eb1, netty-handler-proxy=netty-handler-proxy-4.1.7.Final.7a21eb1, netty-resolver=netty-resolver-4.1.7.Final.7a21eb1, netty-resolver-dns=netty-resolver-dns-4.1.7.Final.7a21eb1, netty-tcnative=netty-tcnative-1.1.33.Fork25.87555d6, netty-transport=netty-transport-4.1.7.Final.7a21eb1, netty-transport-native-epoll=netty-transport-native-epoll-4.1.7.Final.7a21eb1, netty-transport-rxtx=netty-transport-rxtx-4.1.7.Final.7a21eb1, netty-transport-sctp=netty-transport-sctp-4.1.7.Final.7a21eb1, netty-transport-udt=netty-transport-udt-4.1.7.Final.7a21eb1}
2

通过测试结果可知:
首先看App的class测试结果,其依赖的spring的类的classloader是AppClassLoader,其依赖的netty类的classloader是AppClassLoader,版本为4.1.6,与每个bundle的不同。

然后看每个bundle的class测试结果,每个bundle的spring的类是由AppClassLoader加载的,且版本为4.3.6.RELEASE,虽然每个bundle依赖的spring版本都是4.3.7.RELEASE,但因为配置了spring的类为import,因此会从AppClassLoader加载,验证了结果的正确性。

bundle1的BundleFirstImpl使用他自己的classloader加载的,结果正确;bundle1依赖的netty类是由自己的classloader加载的,且netty版本为4.1.8,结果正确。bundle1的BundleFirstApi类是由AppClassLoader加载的,因为该类的包名配置在了import里。

bundle2的BundleSecondImpl使用他自己的classloader加载的,结果正确;bundle2依赖的netty类是由自己的classloader加载的,且netty版本为4.1.7,结果正确。bundle2的BundleSecondApi类是由AppClassLoader加载的,因为该类的包名配置在了import里。

你可能感兴趣的:(一种解决jar包冲突的组件实现)