第2章 OSGi框架简介 前面我们对OSGi及其现状做了一个大体的介绍。下面一起来看我们常用的OSGi框架,也会结合具体的实例让大家来使用这些框架。 2.1 Equinox 2.1.1 简介 2.1.2 环境搭建 既然是基于Equinox开发,我们首先要下载Equinox。Equinox是Eclipse的工程, Eclipse 3.1之后的版本都是通过它来启动的,如果使用的是Eclipse 3.1之后的版本,Eclipse本身就已经包含了Equinox,可在Eclipse的plugins目录下看到类似org.eclipse.osgi_3.4.3.R34x_v20081215- 1030.jar这样的文件(不同版本的Eclipse下对应的版本号和日期会有所不同),它其实就是Equinox的OSGi R4 Core的实现。如果采用的不是Eclipse 3.1之后的版本,建议下载一个Eclipse 3.1之后的版本。 下面我们来检查环境,首先启动Eclipse。 第一步,打开Run Configurations对话框(见图2-1)。
第六步,运行。 点击Run按钮,如果Console中出现"osgi>"并且没有错误信息,说明环境已经正常了。我们可以在osgi>提示符后输入ss,然后回车。将会看到如图2-6所示的界面。
2.1.3 HelloWorld(1) 在这一节中,我们将完成一个HelloWorld的例子。之前大家应该看到过Java语言、C语言或C++等语言中的HelloWorld,那些HelloWorld程序都是在运行后输出一个"Hello World",然后就结束了程序。我们今天的HelloWorld例子程序主要的功能是在启动和停止一个Bundle的时候来做些事情(输出信息)。下面我们就一步一步完成第一个Bundle。 第一步,创建Bundle工程。 在Eclipse中创建一个Plug-in工程(见图2-7)。
输入工程相关的信息,这里和创建普通的Java工程唯一的不同点就是要选择this plug-in is targeted to run with,在这里选择 an OSGi framework的standard选项,也就是说建立一个标准的OSGi Bundle工程(见图2-8)。 输入Bundle的相关元数据信息(见图2-9)。 Plug-in ID 指的是 Bundle 的唯一标识,在实际的项目中可以采用类似 java的包名组织策略来保证标识的唯一性; Plug-in Version 指的是 Bundle 的版本; Plug-in Name 指的是 Bundle 的更具有意义的名称; Plug-in Provider指的是 Bundle 的提供商; Execution Environment指的是Bundle运行需要的环境; 剩下的最关键的就是 Activator部分了,这里填入自己的一个类名就可以了,在工程建立时 Eclipse 会自动建立这个类。
第二步,完成Activator的代码。 打开默认的HelloWorldActivator.java代码(见图2-11)。
2.1.3 HelloWorld(2) 可以看到HelloWorldActivator实现了BundleActivator接口,然后HelloWorldActivator中有两个空的方法--start和stop。其中,start方法是在Bundle被启动的时候调用的,stop是在Bundle被停止的时候调用的,下面我们在这两个方法中加入代码(见图2-12)。
HelloWorld的例子已经完成了,下面看这个例子的运行效果。 第三步,运行。 首先创建一个HelloWorld用的运行配置(见图2-13)。
然后我们设置HelloWorld的Auto-Start属性为false,并且将Target Platform中不需要的Bundle去掉。 再直接点击HelloWorld这个Bundle配置行后面的Auto-Start列的default,在下拉框中选择false,并点击Target Platform前的钩,使得Target Platform下面的项都变为不选择状态。接着我们点击右侧的"Add Required Bundles",这个时候发现Target Platform前的方框变为部分选择的状态,最后我们选中"Only show selected bundles"。这样就完成了运行配置的设置(见图2-14)。
最后点击"Run",在Console中出现"osgi>"提示。这表明已经成功启动了我们的第一个OSGi应用。 在osgi>提示符下输入ss,然后回车,我们可以看到如图2-15所示的显示。
我们可以看到输出了"HelloWorldBundle started!",并且通过ss命令,看到HelloWorld Bundle的状态从前面的RESOVLED变成了ACTIVE,说明我们的HelloWorld Bundle已经成功启动了。并且在Activator的start方法中加入的输出信息也正确打印出来了。 接着,我们输入stop 1,并且再用ss命令查看Bundle的状态,会得到如图2-17所示的反馈。
这个时候HelloWorld Bundle已经被停止。我们在Activator中加入的输出信息正确地输出在了Console,并且通过ss命令看到HelloWorld Bundle的状态从刚才的ACTIVE变为了RESOLVED。 到这里我们完成了第一个OSGi Bundle,也尝试运行了第一个OSGi的程序。在下面的章节,将会看到更加复杂一些的例子。 2.1.5 从外部启动Equinox 前面,我们都是通过Eclipse启动我们的Bundle。但是,在有些时候,我们希望自己来控制OSGi的容器的启动,并且在OSGi的容器外部获取OSGi的服务,甚至是把OSGi的容器内嵌到我们的应用之中。下面我们就来看一下如何把Equinox嵌入到应用中。由应用来启动Equinox、获取OSGi的服务,以及加载OSGi容器中的其他插件的类。并且也会演示OSGi容器中的插件如何加载OSGi容器外的类的方法。 我们在前面演示了如何通过命令行来启动Equinox,常见的一种脚本为:java-jar plugins/org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar -configuration configuration -console,然后在当前的configuration目录下放置一个config.ini,在此config.ini中通过 osgi.bundles=来配置要加载和启动的插件,例如osgi.bundles=example.jar@start,那么要在程序中启动Equinox容 器,其实是做差不多的事情。 通过查看Equinox的代码,会看到调用上面的org.eclipse.osgi.jar后执行的是EclipeStarter中的静态run方法,因此只须在外部传入合适的参数,并调用此run方法即可完成Equinox的启动,在程序中启动Equinox,通常希望做到的是能够指定config.ini 的配置信息及插件的位置,而不是由Equinox去决定。如果不进行设置,默认情况下EclipseStarter将会在工作路径下产生 configuration,并以该configuration目录下的config.ini作为Equinox启动的配置。对于 osgi.bundles配置的bundle的路径,默认则为当前EclipseStarter代码所在的目录,例如上面的命令行,Equinox在启动时就会从plugins目录中去加载插件,这通常是无法满足在程序中启动Equinox的需求的。如果想自定义Equinox启动的配置信息,而不是通过加载指定的configuration中的config.ini,那么可以在程序中调用 FrameworkProperties.setProperty来设置启动Equinox的配置信息。如希望指定osgi.bundles中指定加载的bundle的相对路径,那么可以在Equinox启动的配置信息中增加osgi.syspath的设定:FrameworkProperties.setProperty("osgi.syspath",你希望指定的bundle所在的路径)。Equinox启动的配置信息还有很多种,有具体需要的话可以查看EclipseStarter中processCommandLine的方法。通过这样的方式,就可以启动Equinox:EclipseStarter.run(new String[]{"-console"},null);按照上面的方式就可以实现在外部程序中启动equinox了。 OSGi通过BundleContext来获取OSGi服务,因此想在OSGi容器外获取OSGi服务,首要的问题就是要在OSGi容器外获取到BundleContext,EclipseStarter中提供了一个getSystemBundle- Context的方法,通过这个方法可以轻松拿到BundleContext,而通过BundleContext则可以轻易拿到OSGi服务的实例。不过这个时候要注意的是,如果想执行这个OSGi 服务实例的方法,还是不太好做的,因为容器外的classloader和OSGi服务实例的class所在的classloader并不相同,因此不太好按照java对象的方式直接去调用,更靠谱的是通过反射去调用。 如果想在容器外获取到OSGi容器里插件的class,一个可选的做法是通过BundleContext获取到Bundle,然后通过Bundle来加载 class,采用这样的方法加载的class就可以保证是相同的。否则会出现容器外的一个A.class不等于容器里插件的A.class,其中原因对于稍微知道java classloader机制的人都是理解的。 按照上面的说法,一个简单的启动Equinox及与OSGi容器交互的类可以这么写:
在实现了OSGi容器外与OSGi交互之后,通常会同时产生一个需求,就是在OSGi容器内的插件要加载OSGi容器外的类,例如OSGi容器内提供了一个mvc框架,而Action类则在OSGi容器外由其他的容器负责加载,那么这个时候就会产生这个需求了,为了做到这点,有一个比较简单的解决方法,就是编写一个Bundle,在该Bundle中放置一个允许设置外部ClassLoader的OSGi服务,例如:
基于上面的方法,在外部启动Equinox的类中去反射执行ClassLoaderService这个OSGi服务的setClassLoader方法,将外部的classloader设置进来,然后在OSGi容器的插件中要加载OSGi容器外的类的时候就调用下面这个ClassLoaderService去完成类的加载。 基于以上说的这些方法,基本上可以较好地实现OSGi容器与其他容器的结合,例如在tomcat中启动OSGi等,或者在我们自身的应用中来控制OSGi的容器。到这里,我们基本上完成了对于Equinox的介绍,下面来看另外一个应用也较广泛的OSGi的容器--Felix。 |
|