eddle的专栏

OSGi 的 Event Admin 服务规范提供了开发者基于发布 / 订阅模型，通过事件机制实现 Bundle 间协作的标准通讯方式。事件发布者使用 Event Admin 服务发送基于主题 (Topic) 的事件，任何对某一主题感兴趣的事件订阅者都会收到该事件，并且做出相应的反应。如何发布事件我们遵循以下的步骤，通过 Event Admin 发布事件：获得实现了 org.osg

MANIFEST.MFMANIFEST.MF 可能出现在任何包括主类信息的 Jar 包中，一般位于 META-INF 目录中，所以此文件并不是一个 OSGi 特有的东西，而仅仅是增加了一些属性，这样也正好保持了 OSGi 环境和普通 Java 环境的一致性，便于在老的系统中部署。表 2 列出此文件中的重要属性及其含义：表 2. MANIFEST.MF 文件属性

OSGi服务：非常适合SOA的架构本文介绍OSGi服务。OSGi架构非常适合我们实现面向服务的应用(SOA)。OSGi具有隐藏真实的服务实现类的能力，所以它为面向服务的应用提供了良好的类与接口的组合。OSGi服务前面我们提到，OSGi架构非常适合我们实现面向服务的应用(SOA)。它可以让Bundles导出服务，而其它的Bundles可以在不必了解

基于OSGi的动态化系统搭建本文向您介绍基于OSGi的动态化系统的搭建，对动态化系统的优点和基于OSGi的搭建做简单的演示。搭建动态化的系统是作为Java开发人员一直就非常追求的目标，一个系统能够动态化就意味着：◆ 添加新功能时不需要重启系统；◆ 修改已存在的功能时不需要重启系统；◆ 删除一些不需要的功能时不需要重启系统；◆ 修改系统

OSGi依赖性管理：Bundle访问域OSGi依赖性管理OSGi允许您把您的应用程序分成多个模块，并能管理这些模块之间的依赖性。为了达到这个目的，它引入了Bundle访问域的概念。Bundle中类的缺省访问范围只对本Bundle内部可见，但对其它任何Bundle都是不可见的；在Bundle内部，类的可访问性遵循Java语言的一般规范。那么，您如果想要从一个Bundle中

http://developer.51cto.com/art/200909/154863.htm

OSGi,Java模块化框架的另类进化(2)在我们这个模块系统中，我们选择的解决方式是允许模块仅“导出”其内容的一部分。如果模块中某些部分是非导出的，那么对于其他模块就是不可见的。但默认导出哪些内容？除了某些明显需要隐藏的部分，我们应该导出所有内容吗？或者除了那些明显需导出的部分，我们应该隐藏所有其他内容？选择后者看起来能够到来更好的透明度：我们可以很方便查看导出列表，确定那些可见

OSGi,Java模块化框架的另类进化(3)对模块和元数据进行打包我们这个模块系统需要一种方法来对模块的内容以及描述导入和导出的元数据进行打包，将其包括到一个可部署的单元中。Java 已经有了标准的部署单元：JAR 文件。JAR 文件可能并不算一种非常成熟的模块，但对于移动大块的编译代码还是不错的，所以我们并不需要创建新的东西。那么现在的唯一问题是，将元数据（即导入和导

OSGi,Java模块化框架的另类进化(1)我们曾不只一次的听到2010年将是Java模块化的一年的言论；也知道目前为Java提供模块化的OSGi正在受到IBM和Eclipse基金会的大力支持。但作为实现Java模块化应用的基础框架，OSGi似乎并不完美；我们经常能听到关于OSGi过于复杂的抱怨。从个人的角度，我以开放的心态去了解OSGi。令人失望的是，我发

在目前的 Java 开发平台中，对于组件开发过程，比如打包、部署和验证等，并没有一个统一的标准。正因如此，许多 Java 项目，例如 JBoss 和 Net Beans，都拥有一套自定义的组件开发规范和框架，但是实际上这些解决方案都是基于为组件分配独立的类加载器 (Class Loader) 的思想。 OSGi 框架为基于 Java 的组件开发提供了一套通用的和标准的解决方案，并已经成为事实上的工