Equinox,我不想多做介绍,相信很多人都有所了解了,不了解的可具体去www.eclipse.org/equinox看看。
最近基于equinox做了一个系统,还是碰到了一些问题,当然也得到了在插件体系架构下的不少优点,在这里也做个总结。
总体而言,基于equinox做开发对于大多数java开发人员来说应该不会有太多改变的感觉,最多改变的感觉应该是带给设计师,设计师需要有发挥插件体系架构优点以及减少其带来的缺点的能力,^_^
1、部署不是很方便
equinox默认提供的是一个console端的插件部署管理,部署起来需要通过"install reference:file://"这样的方式来安装插件,不是特别的方便。
^_^,由于我当时使用的时候equinox还没提供osgi中httpservice的实现,便使用了oscar中提供的httpservice的实现,基于这个httpservice的实现写了一个web端的插件管理的工具,呵呵,将来整理后会将这个bundle公布出来,到时大家直接下载就可以用了。
在部署方面还有一个不方便的地方就是不能指定插件的启动顺序,现在equinox是通过config.ini中来实现插件启动顺序的控制的,这个在我的web端的插件管理工具中也提供直接,可直接设定插件的启动顺序。
2、Classpath的问题
这个问题是我在使用equinox时比较头疼的一个问题,我在bundle中使用了spring IoC container,而由于spring中使用的不是当前类的加载器,导致在加载配置文件的时候会出错,只得直接修改了spring中那些部分的代码,将其改为使用当前类的加载器。
在集成其他一些自己含有classpath的东西的时候也很容易出现这个问题。
虽然从原理上来讲这个是可以理解的,因为在插件体系结构中每个插件都拥有独立的插件类加载器,这个确实会对集成的有些东西产生影响,抑或我们应该理解为集成的那些东西在这方面设计有缺陷?
3、有利于面向接口编程的执行
这个应该说是属于插件体系结构的好处,每个插件可以控制自己对外所暴露的包,这个时候就可以只暴露接口所在的包,^_^,呵呵,面向接口的编程就这么被强制的执行了。
4、插件开发的IDE
这点是我觉得equinox的天然优势,拥有一个eclipse这么优秀的插件开发的IDE,^_^
支持了插件的调试...
我认为的最重要的一点是它解决了插件依赖的问题,通常在出现project依赖的时候我们都需要引用该project或是该project生成的jar,而在插件体系结构中只需要在插件文件中定义所依赖的包即可,这个就解决了去引用project那样方式引起整个项目工程包混乱和开发不便的现象。
5、插件的测试
这点我想也是大家很关心的,不过大家可以放心,基本没什么不同的,unit test继续使用Mock方式完成所测试的unit的外部依赖的部分,集成测试则需要启动equinox容器,这点应该没什么不能接受的。
6、Bundle和Service的定义
这个就是插件体系结构带来的一个挑战,如果准确的定义系统中的bundle和service是很关键的一个问题,这对于发挥插件体系结构的bundle级别、service级别的重用性至关重要,同时对于整个项目结构的清晰度也会产生很大的影响,形成bundle的清晰的service依赖结构。
7、面向服务的体系
我想这也同样是象equinox这样的插件框架引发使用者的思考,系统采用的应该是一种面向服务的体系,服务才是系统的核心,bundle只是一个管理器而已,这个时候怎么样设计出动态、松散耦合的服务体系是很关键的。
equinox一直都在发展之中,它的maillist一直就非常的热闹,而且现在对于osgi中的service它基本都实现了,也已经开始提供对于servlet container集成的支持,^_^,极度支持equinox,虽然它还需要不断的努力.....
可以看得出,经过我上面的总结,大家其实要担心的是引用一种新的体系结构带来的设计层面的变革,而不是开发实现层面,^_^
![34930.html](https://i-blog.csdnimg.cn/blog_migrate/236e901d5c8772d6530d6ab52a17fa0c.jpeg)