电脑故障

位置:IT落伍者 >> 电脑故障 >> 浏览文章

OSGI实战和进阶


发布日期:2023/1/28
 

这两天才看了BlueDavy的《OSGI实战》和《OSGI进阶》篇写得很好的文档

实战可做OSGI的入门资料进阶可做OSGI的实践资料

很感谢BlueDavy大大的文档他的BLOG是

进阶中讲解了一个留言板的例子基于Spring/Hibernate/WebWork/OSGI

其中提供了Hibernate和WebWork的OSGI集成方案实现很精彩Spring则采用springosgi

其留言板的例子是按应用模块进行划分的并用Equinox的扩展点方式展现了菜单的加载和卸载实例虽然这个菜单仅仅是一个链接但也颇有参考意义

此外还有如何将现有系统重构成OSGI系统的讲解并总结了自己对OSGI应用中的设计模式和最佳实践的理解

这是目前我看到的最好的OSGI的中文资料了

该书对模块的划分很细(其实不是基于功能模块而是基于用例了)可能是因为留言板的例子太过简单只好如此来演示我想在实际的项目中不会以这样的细粒度进行分模块的开发否则BUNDLE会多不胜数反而给维护带来麻烦

在BlueDavy总结的最佳实践中我认为接口和实现分离为不同的Bundle不是一个好的实践搞太多的BUNDLE不是好事情把接口BUNDLE挂着只对实现BUNDLE进行热插拔与将接口和实现放在一个BUNDLE中做热插拔是一样的

使用springosgi时就需要导入那么多的BUNDLE我想最好能提供一个集成的BUNDLE让开发者更容易搭建开发环境当然也提供零散的BUNDLE让开发者可以自行选择需要的就像有springjar也有springbensjar/springcontextjar/springaopjar一样

现在搭建一个springosgi的开发环境还是挺麻烦的在下载的springosgiM的lib中还少了一些BUNDLE只好在M中去找spring发行的jar包将会同时支持普通开发和OSGI开发那时可能会方便一点现在还是rc的版本没有试验是否可用

现在在实际项目中运用OSGI风险还是太大spring和strut正式发布时应该才是引入OSGI到实际项目的时机

上一篇:如何将字串 String 转换成整数

下一篇:使用Log4j进行日志操作