OSGI in Action 读书笔记第三章

最新推荐文章于 2020-07-08 11:58:54 发布

xyz0101123132

最新推荐文章于 2020-07-08 11:58:54 发布

阅读量1k

点赞数

CC 4.0 BY-SA版权

分类专栏： OSGI 文章标签： osgi action 读书 osgi框架 binding 框架

本文链接：https://blog.youkuaiyun.com/gudong2945/article/details/7924257

OSGI 专栏收录该内容

3 篇文章

订阅专栏

本文探讨了OSGi框架中bundle的生命周期管理，介绍了生命周期层的功能及其重要性。文章详细讲解了如何利用OSGi API进行bundle的安装、启动、停止等操作，并讨论了BundleActivator的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

OSGI in Action 读书笔记第三章
第三章学习生命周期
   本章将帮助您熟悉的生命周期层的功能，并解释如何有效地使用它们。在下一节中，我们将仔细看看什么生命周期管理，为什么你应该关心它的定义，其次是OSGi包的生命周期。在随后的章节中，您将了解的API，用于管理bundle的生命周期。
3.1 lifecycle层介绍
   1、在应用程序外部定义了bundle的生命周期操作。
   2、在内部定义了如何使bundle访问OSGI的执行上下文
3.1.1 什么是生命周期管理
   通过JMX、及普通的桌面应用程序说明了生命周期一般要经历的过程：安装、执行、更新、卸载。
   通过Standard Java及Servlet说明java是如何管理其生命周期的。
3.1.2 为什么要使用生命周期管理
   1、提供了更细粒度的生命周期管理——bundle的生命周期管理；
   2、提供了一组标准的生命周期管理API；
   3、可以按需使用组件，为应用程序提供更多的灵活性。
3.2 OSGI bundle的生命周期
   在module层，我们为其提供了原数据，已支持其模块性，而生命周期层则不需要依赖于任何的元数据或xml配置文件，他所依赖的是一组标准的api.
   由于没有标准的方式为用户进行交互的生命周期API，你可以使用一个基于OSGI标准的框架框架。但是，这将使我们错失一个很好的学习的机会。
小贴士：壳、壳、壳到处是壳
   在OSGI标准的多个实现中（如：Apache Felix, Eclipse Equinox,Knopflerfish）都定义了自己的Shell,用以与运行的OSGI交互。OSGI并没有定义标准的Shell，尽管osgi做了一些相关的工作，但是Shell不必绑定到特定的框架，shell也可以作为bundle实现，就像你在这里做的一样。
3.2.1介绍生命周期的画图程序
   使用Paint程序展示OSGI的动态性。值得研究的还有telnet通讯。
   使用的示例shell和paint，采取自上而下的的方法来学习：
   在3.2.2节中，我们将解释在应用程序的生命周期中框架承担的角色。
   在3.2.3节中，我们来看看需要对manifest做如何调整已使bundle钩如到OSGI框架中。
   在3.2.4节中，我们将研究OSGi生命周期的关键API接口：BundleActivator, BundleContext,Bundle。
   在3.2.5节中，在结束时，议论OSGi的生命周期状态图。
3.2.2 在生命周期管理中OSGI框架担任的角色
   在标准的Java编程中，可以将JAR文件放置在类路径中，已完成jar包的导入（安装），但这不是安装bundle的方法。bundle在使用之前必须安装到正在运行的OSGi框架实例。从概念上讲，你可以认为安装bundle就类似于将一个JAR文件放置到标准java的类路径中。
   一个很大的区别的是，OSGi框架支持对bundle完整的生命周期管理,包括安装、解析、启动，停止，更新和卸载。到此，我们只谈到了安装bundle并解决他们的依赖关系。本章的其余部分将全面解释生命周期的活动，以及他们是如何相互关联的。例如，我们已经提到过，框架不允许bundle使用，直到它的依赖满足。
   另一个重大区别是，OSGi框架在运行时对bundle提供完整的生命周期管理支持。这类似于动态的修改类路径！
   作为生命周期管理的一部分，框架对安装包(bundle)进行了缓存，并做了持久化。这意味着下一次启动的框架，任何安装包将自动重新加载到缓存中，原JAR文件不再需要了。或许这可以作为一个框架的特点：受控的，动态的，持久化的类路径。这听起来很酷，对吧？如何让我们继续？你必须修改元数据，允许bundle钩入到生命周期层的API。
3.2.3 manifest的bundle activator元素
   Bundle-Activator: org.foo.shell.Activator
小贴士 Bundle-Activator是不是必须的？
   BundleActivator并不是对于每个bundel必须的。只有那些需要与OSGI AIP交互的或者需要定制其初始与销毁行为的bundle才需要。没有Activator的Bundle并非没用。他可能提供一些公用的Class
3.2.4 生命周期管理API介绍
   BUNDLE ACTIVATOR
   public interface BundleActivator {
       public void start(BundleContext context) throws Exception;
       public void stop(BundleContext context) throws Exception;
   }
   Simple shell bundle activator
   package org.foo.shell;
   import org.osgi.framework.BundleActivator;
   import org.osgi.framework.BundleContext;
   public class Activator implements BundleActivator {
       private volatile Binding m_binding;
       public void start(BundleContext context) {
           int port = getPort(context);
           int max = getMaxConnections(context);
           m_binding = getTelnetBinding(context, port, max);
           m_binding.start();
           System.out.println("Bundle " +
           context.getBundle().getSymbolicName() +
           " started with bundle id" +
           context.getBundle().getBundleId() +
           " listening on port " + port);
       }
       public void stop(BundleContext context) {
           m_binding.stop();
       }
       ...
   }
   ...
   public interface Binding {
   public void start();
   public void stop() throws InterruptedException;
   }
   当bundle被装载且开始的时候，框架实例化一个Activator并且调用start()方法。当bundle结束的时候，调用已实例化的Activator的stop()方法。当stop()方法调用时。Activator的实例将被丢弃。如果对一个已经停止的bundle重新开始。则重新实例化一个新的Activator实例。
   OSGI规范并不要求你在start()方法中启动一个新的进程。

小贴士 OSGI的线程安全问题

OSGi是普通的Java线程抽象设计的。不像其他的大多数重量级的框架，它假定你自己对线程进行管理。这样你获得了更多的自由，但同时你必须确保你的
程序正确同步和线程安全。在这个简单的例子中，没有什么是特别是必要的，但在一般情况下，你很可能在不同的线程中调用stop()和start()方法。
OSGi的库是线程安全的，并且通常是在回调的方式给你一定的保证。例如，在bundle activator中start（）和stop()以保证按顺序调用，不能同时使用。所以，在技术上，
这种特殊情况下的挥发可能不是必要的。