肖伯纳人生有两大悲剧:真正的猛男,敢于鄙视OSGi-回帖
真正的猛男,敢于鄙视OSGi
该帖已经被评为精华帖
作者
正文
- galaxystar
- 等级:
- 性别:
- 文章: 631
- 积分: 2483
- 来自: 杭州
发表时间:2010-03-10 最后修改:2010-03-11
<>猎头职位: 北京: JavaEye招聘Java搜索工程师
相关文章:
- 基于osgi开发大型的企业应用
- 想做个基于OSGI插件体系的web开发框架,欢迎大家拍砖
- web应用中加入osgi支持
推荐圈子: 博文视点
更多相关推荐
ADAM BIEN这位老兄,最近在他的blog上发表了一篇关于“如何杀死一个OSGi项目”(How to kill a OSGi projcet)的主题,引来了无数口水。
说实话,我个人还是很赞同老兄的部分观点。 单从它提出的10个问题来看,有一半是大多数公司和开发人员正面临要解决的问题。
看来这位老兄,私下也是做了不少功课的,人猛才是王道。
参考他提出的10个问题,来看我们公司的使用情况,大致有三个方面被他说中了:
1,有状态的bundle想要做平滑热替换,需具备一定复杂性。
最近,一位公司同事正在实验某个带状态bundle的热替换工作,开发期间碰到了多处棘手的问题(实例状态的同步转移),幸好人牛,从他描述的实现逻辑来看,必然包含很复杂操作在里面。
可见有状态bundle的平滑热替换,很难简单实现。
2,当OSGi的bundle数量达到一定规模时,维护成本必将成为瓶颈。
这是一个趋势,值得庆幸的是,从我们公司项目的bundle数量来看,还未迈入“成年”。对策尚可暂缓考虑。
3,多个版本或相互依赖bundle间的测试必然会显著提高复杂性。
谁能推荐个好用的OSGi测试框架?
问题中还提到分发包的增量更新,RCP应用程序的暴露问题,貌似我们公司没用到。但看得出来,OSGi也不是万能的。成熟度还有待提高。。。要知道JDK7的jigsaw(JSR294 and 277)已在养精蓄锐了,从language, compiler, vm等底层入手做modularity的jigsaw,对OSGi造成的压力可不小啊。
希望将来有位猛男能够趟一趟这浑水,像我这样的迷茫者就可以随波逐流了。。。
转自主博:http://kenwublog.com/look-reality-in-fault-of-the-osgi
声明:JavaEye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
- 实用工具推荐,延长电池续航时间
- 入学不花1分钱学JavaEE+3G 就业"不做开发不还款"
-
返回顶楼
- wl95421
- 等级:
- 性别:
- 文章: 284
- 积分: 633
发表时间:2010-03-11
你这是标题党
1、bundle的热更换,主要是口号,而不是实用,拿这个主要是忽悠人的,热替换,不管怎么做,都是复杂的。
2、bundle数量多了,难以维护,难道Jar多了,就好维护,这是个伪命题。
3、我主业做Eclipse开发,所以用Eclipse的JUnit Plugin还是比较好用的,不知道能满足要求不?
4、JDK7的Module,引发的问题,不见得比OSGi少。
5、目前,J2EE和OSGi的整合是比较困难的。
返回顶楼
回帖地址
1 0 请登录后投票
- galaxystar
- 等级:
- 性别:
- 文章: 631
- 积分: 2483
- 来自: 杭州
发表时间:2010-03-11
wl95421 写道
你这是标题党
1、bundle的热更换,主要是口号,而不是实用,拿这个主要是忽悠人的,热替换,不管怎么做,都是复杂的。
2、bundle数量多了,难以维护,难道Jar多了,就好维护,这是个伪命题。
3、我主业做Eclipse开发,所以用Eclipse的JUnit Plugin还是比较好用的,不知道能满足要求不?
4、JDK7的Module,引发的问题,不见得比OSGi少。
5、目前,J2EE和OSGi的整合是比较困难的。
Yes,我就是标题党,:),此标题是第三人称。
1,3,5 clear
2,jar的粒度通常情况下大于bundle. jar的依赖管理有很成熟的工具-maven。
4,我断言Jigsaw要比OSGi发展稳健,腰板直,才能走得快。
返回顶楼
回帖地址
0 0 请登录后投票
- freej
- 等级: 初级会员
- 性别:
- 文章: 443
- 积分: 40
- 来自: 北京
发表时间:2010-03-11
综上所述,OSGi是个很复杂的标准,并不建议一般应用去去实现它。
返回顶楼
回帖地址
0 0 请登录后投票
- hzh0725
- 等级: 初级会员
- 性别:
- 文章: 19
- 积分: 80
- 来自: 上海
发表时间:2010-03-11
OSGI只是一个标准,或者说接口,说的更通俗一点,就是一个让各个模块组织方法,你不用去考虑怎么组织了,比如 生命周期,启动顺序,模块之间的关系(service,package)。
从上面来说OSGI又是一个平台,是一个很小的平台。
其实osgi很简单,用的不好,我觉得是你自己的项目大框架和模块本身就不太清晰,跟osgi没有太大关系。
比如你自己写一个eclipse plugin,在eclipse里面没有work properly,跟eclipse没有太大的关系。
返回顶楼
回帖地址
0 0 请登录后投票
- wl95421
- 等级:
- 性别:
- 文章: 284
- 积分: 633
发表时间:2010-03-11
2、bundle和jar的粒度问题和公司,还和设计风格,规范都有关系,事实上两者并没有必然大或小的联系。
4、这个没有什么争论的,就象weblogic和websphere谁好一样,背景,应用都不同,比较是没有意义的。我只能说对于现有系统,OSGi可能更好处理一些,而于新的系统,则不好说。
返回顶楼
回帖地址
0 0 请登录后投票
- xyz20003
- 等级:
- 性别:
- 文章: 798
- 积分: 1427
- 来自: 唐山
发表时间:2010-03-11 最后修改:2010-03-11
2,jar的粒度通常情况下大于bundle. jar的依赖管理有很成熟的工具-maven。
这点不敢苟同,业务系统中的bundle应该是jar的集合,只想把jar转换成bundle就当做依赖管理完全是本末倒置。
4,我断言Jigsaw要比OSGi发展稳健,腰板直,才能走得快。
对jigsaw不熟悉,但是根据以往经验,java官方的标准都是巨复杂,巨难用,好用的东西都是从先从社区得到了实践锻炼,再慢慢一步一步向标准化发展,就像OSGi这样。
最后一个问题:到底应不应该用OSGi?
要说这个问题,首先要问:“能力够不够啊?”OSGi这东西对大多数业务应用来说,完全是鸡肋,吹嘘动态模块热插拔,最后项目却是按照紧耦合设计的,业务相互之间复杂依赖,最终得到的只有高昂的技术难度代价。
然后要问:“你用的项目真的需要动态模块化吗?”实际上大多数都是不需要的,那为啥还要用OSGi?忽悠概念,就像BPM,SOA一样,本来用不着,但是为了添名词,所以就加上了。
最后可以回答上面的问题了,“既然你能力够牛,实际又真需要动态模块化,那么为何不用OSGi呢?”至少人家把规范都写好了,帮你省去不少的功夫,这种东西还是有一定技术难度的,手工去造个轮子的难度也不小。
返回顶楼
回帖地址
0 0 请登录后投票
- galaxystar
- 等级:
- 性别:
- 文章: 631
- 积分: 2483
- 来自: 杭州
发表时间:2010-03-11
wl95421 写道
2、bundle和jar的粒度问题和公司,还和设计风格,规范都有关系,事实上两者并没有必然大或小的联系。
4、这个没有什么争论的,就象weblogic和websphere谁好一样,背景,应用都不同,比较是没有意义的。我只能说对于现有系统,OSGi可能更好处理一些,而于新的系统,则不好说。
3,clear,使用习惯不同。
4,比较怎么能说没意义呢?至少能够让我们看到两个不同标准之间各有什么优缺点。
要是jigsaw release了,我还是有兴趣做一下对比的。(网上已有很多对比)
返回顶楼
回帖地址
0 1 请登录后投票
- galaxystar
- 等级:
- 性别:
- 文章: 631
- 积分: 2483
- 来自: 杭州
发表时间:2010-03-11 最后修改:2010-03-11
xyz20003 写道
2,jar的粒度通常情况下大于bundle. jar的依赖管理有很成熟的工具-maven。
这点不敢苟同,业务系统中的bundle应该是jar的集合,只想把jar转换成bundle就当做依赖管理完全是本末倒置。
4,我断言Jigsaw要比OSGi发展稳健,腰板直,才能走得快。
对jigsaw不熟悉,但是根据以往经验,java官方的标准都是巨复杂,巨难用,好用的东西都是从先从社区得到了实践锻炼,再慢慢一步一步向标准化发展,就像OSGi这样。
3,clear, 你所有bundle都是jar的集合?貌似我只把sharable的jar做了聚合。当然粒度这个确实是看风格的。
4,我感觉java版OSGi(eqinox, felix, your own)在目前language层面上,已经把模块化发挥得淋漓尽致了。要想有更大的作为,不得不走邪门歪道。jigsaw旨在提供更多OSGi标准无法解决的问题的一些实现方案,标准复杂我感觉关系不大,可以优化(有OSGi标准作为参考,未必很复杂),但这应该是个趋势。
返回顶楼
回帖地址
0 0 请登录后投票
- xyz20003
- 等级:
- 性别:
- 文章: 798
- 积分: 1427
- 来自: 唐山
发表时间:2010-03-11
当然也不是所有bundle都是粗粒度的,但是请考虑一个问题,如果bundle都是以jar为单位,那么怎么体现classLoader隔离不同版本依赖的效果呢?
比如一个模块依赖jar-1.0,另一个模块依赖jar-2.0,如果没有osgi,想解决这个问题就只能把其中一个模块改掉。用了osgi就可以考虑,把jar-1.0作为模块一的classpath,jar-2.0作为模块二的classpath,每个模块向外暴露自己的接口,内部管理本身的依赖。
java本身对模块化支持确实有限,所以osgi才跑出来了嘛,个人感觉osgi现在就挺好的了。或许举出几个osgi难以实现的场景来,会比较便于大家讨论。上边说的这些都是设计上的问题哦。