Eclipse3.0平台简介
作者:张增志
概要
Eclipse3.0平台与Eclipse2.1平台的一个重要的区别就是,Eclipse3.0平台建立在一个Java框架上,即Open Services Gateway Initiative(OSGi)服务平台.OSGi的采用,使Eclipse走上了完全动态平台的发展道路.本文先简要介绍OSGi框架,然后介绍OSGi框架和Eclipse3.0平台的联系.
一. OSGi框架简介
URL:http://blog.blogchina.com/upload/2004-11-24/20041124110530659453.jpg
图1:Eclipse3.0架构
如上图所示,Eclipse3.0平台是建立在OSGi(Open Services Gateway Initiative)服务平台基础之上的,所以有必要先介绍一下OSGi框架.
OSGi框架
OSGi框架是一个通用,安全,可管理的Java框架,它支持被称为"bundle"的可扩展和可下载的服务应用的部署.与OSGi兼容的设备可以下载和安装基于OSGi标准的bundle,并且还可以删除不再需要的bundle.另外,已安装的bundle可以注册一组服务(service),这些服务可以在OSGi框架的严格控制下被其他bundle共享.
OSGi框架以一种动态和可升级的方式管理哪些处于OSGi环境中的bundle的安装和更新,还管理bundle和服务(service)的依赖关系.
Bundle
在OSGi服务平台中,bundle是部署的Java应用的唯一实体.一个bundle由Java类和其它资源组成,它们提供功能给终端用户,提供服务组件(serveices)给其它的bundle.
Bundle是作为JAR文件被部署的.可以说,一个bundle就是一个JAR文件,它包括:
1> 容纳了实现零个或多个服务的资源.这些资源可以是Java类文件,也可以是其它数据文件如HTML文件,图标文件等.
2> 容纳了一个manifest文件.该文件描述了JAR文件的内容和与bundle相关的配置信息.
3> 陈述了对其他资源如Java中的包(package)的依赖关系.
4> 指明bundle中的一个Java类作为Bundle Activator接口的实现类.OSGi框架必须实例化该类并调用start和stop方法来启动和停止bundle.
MANIFEST.MF文件
每一个bundle都有一个描述其自身信息的MANIFEST.MF文件,该文件位于JAR文件中的META-INF目录下.
我们知道,在生成普通的Java JAR文件时都会要求指定一个MANIFEST.MF文件与该JAR文件关联在一起.MANIFEST.MF文件的内容格式可能如下:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.3
Created-By: 1.4.2_04-b05 (Sun Microsystems Inc.)
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.3
Created-By: 1.4.2_04-b05 (Sun Microsystems Inc.)
上例中显示的是一组MANIFEST头(header)/值(value)对,如Bundle-Activator头(header)的值为test.osgi.exam2.Activator.
在OSGi框架定义了一组标准的MANIFEST头(header),每一个header都有其特定的含义.上例中定义的Bundle-Activator头信息的值test.osgi.exam2.Activator表示用来启动和停止"English dictionary" Bundle的类名. Export-Package头信息的值test.osgi.exam2.service表示可以被导出的包名,即test.osgi.exam2.service包可以被其它Bundle导入并使用其中提供的服务(service).
Bundle的受控状态
一个Bundle可能处在下面的状态之中:
■ 已安装(installed)
在OSGi框架安装Bundle时,将解析该Bundle的本地代码的依赖关系.如果失败,该Bundle将不会被安装.一旦Bundle被安装,OSGi框架将可对该Bundle的整个生命周期(如起动,停止,更新,卸载)进行控制.
■ 已解析(resolved)
当OSGi框架成功地解析Bundle的本地代码的依赖关系时,该Bundle就进入解析状态.这些依赖关系包括:
1> Bundle的MANIFEST.MF文件中,MANIFEST头Bundle-Classpath定义的类路径依赖关系.
2> Bundle的MANIFEST.MF文件中,MANIFEST头Export-Package和Import-Package定义的依赖关系.
■ 起动(starting)
一旦Bundle被起动,该Bundle的状态就被设置为ACTIVE,并一直持续到该Bundle被停止.在起动前,MANIFEST.MF文件中MANIFEST头Bundle-Activator定义的类将被实例化,该类实例的start方法被调用以起动Bundle.
■ 停止(stopping)
一旦Bundle被停止,该Bundle的状态就被设置为RESOLVED.在停止前,上文中提到的Bundle-Activator类定义的stop方法被调用以停止Bundle.
■ 激活(active)
已经被激活的Bundle可以进行自身状态的更新.在任何时候,OSGi框架只能满足一个Bundle的唯一版本可用.Bundle的更新操作支持该Bundle移植到一个高版本或向后兼容的版本.
■ 已卸载(uninstalled)
在卸载前,上文中提到的Bundle-Activator类定义的uninstall方法被调用以卸载Bundle,该方法将使OSGi框架提醒其他Bundle它正在进行卸载操作,并设置该Bundle的状态为UNINSTALL.如果该Bundle与其他Bundle存在关系,如它导出一些被其他Bundle使用的包(即该Bundle的MANIFEST文件中定义了Export-Package值),OSGi框架在没有被重启的情况下将继续确保这些包仍可用.如果该Bundle与其他Bundle没有关系,OSGi框架将恢复到该Bundle被安装前的状态.
下面的Bundle状态图描述了Bundle的受控状态.
URL:http://blog.blogchina.com/upload/2004-11-24/20041124110552991489.jpg
图2
类装载(Class Loading)
Bundle就是一个JAR文件,OSGi框架所面临的首要问题就是,怎样去获取随时可能被"扔进"框架中的Bundle内的类文件和其它资源.
对于每一个已安装或已解析的Bundle,OSGi框架都会建立该Bundle的Classloader.这个Classloader还被建立在下面图3所示的委托模型中.
URL:http://blog.blogchina.com/upload/2004-11-24/20041124110606586667.jpg
图3
其中:
1> Bootstrap类装载器装载Java核心API中的类.
2> SystemClassLoader类装载器可以是系统类路径类装载器和标准扩展类装载器,还可以是其他用户自定义类装载器,装载系统CLASSPATH上的类或Java扩展路径上的类或用户指定的类.
3> BundleClassLoader类装载器装载该Bundle的MANIFEST文件中Bundle-ClassPath头所指定的类文件.如果该Bundle需要导入其它Bundle中导出的包,那么这些Bundle的类装载器的实例也要被建立在如图3所示的委托模型中,并为该Bundle提供它所需的类.
上文中只是对OSGi框架进行了简短地介绍,关于它的详细信息请参照: http://www.osgi.org
二. Eclipse3.0插件和OSGi Bundle
OSGi服务平台规范是一个开放的架构,用户可以根据自己的需要来实现这个规范.Eclipse3.0就提供了该规范的一个实现.
我们知道,在OSGi中基本的模块单元是Bundle,在Eclipse中则是插件(plug-in).在Eclipse2.1中,插件往往表现为plugins目录下的一个文件夹.例如如下的目录结构:
+ D:\eclipse
+ plugins
+ eclipseme
+ docs
+ icons
+ lib
- about.html
- CHANGES.txt
- CREDITS.txt
- eclipseme.jar
- JETTY-LICENSE.html
- LICENSE.txt
- plugin.properties
- plugin.xml
- README.txt
- toc.xml
+ org.apache.ant_1.5.3
上述eclipseme插件提供了Eclipse2.1平台和J2ME的集成.在每一个Eclipse2.1插件中,都包含一个plugin.xml文件,其中描述了插件名,版本号,需要的JAR包和插件要使用的扩展点等等.
■ plugin.xml 插件清单文件
■ plugin.properties 容纳被plugin.xml引用的字符串.
■ about.html 证书信息
■ *.jar 插件需要的类文件
■ lib 容纳第三方JAR包
■ icons 容纳icon文件,通常是GIF格式
■ docs 容纳文档文件,通常是HTML格式
■ toc.xml 文档结构清单文件
■ (other files)
在Eclipse3.0中,插件不仅表现为plugins目录下的一个文件夹,还包括一个MF文件.这个MF文件可以位于该插件文件夹下.也可位于configuration\org.eclipse.osgi\manifests目录下.如:
例1:
+ D:\eclipse
+ configuration
+ org.eclipse.osgi
+ manifests
- eclipseme_0.1.0.MF
例2:
+ D:\eclipse
+ plugins
+ org.eclipse.osgi_3.0.0
+ META-INF
- MANIFEST.MF
在Eclipse3.0中,插件也可被称为Bundle.Bundle的类文件和资源文件就是插件文件夹下的JAR文件和其他资源文件,Bundle的MANIFEST文件就是上文中提到的MF文件.
Eclipse的插件信息是被配置在plugin.xml中的.OSGi Bundle信息是被配置在MANIFEST.MF文件中的.下面就说说它们的联系.
plugin.xml包括三个部分的信息.
1> 插件基本信息.如插件名,插件ID号,插件版本号,插件提供者名和插件类的全限定名.
2> 插件的依赖关系和插件的运行库.
3> 插件的扩展和扩展点.
在Eclipse3.0中,前两部分的信息可以被配置在MANIFEST.MF文件中.如Eclipse3.0中的runtime插件.考虑到与Eclipse以前版本的兼容,plugin.xml文件仍然支持对上三部分信息的配置格式.但是,Eclipse3.0平台运行在处理插件信息时,它认为插件是一个Bundle外加上扩展和扩展点.
Eclipse2.1的平台运行内核缓存所有插件的注册信息在Registry API中,所有这些信息是从.registry文件中或解析所有的plugin.xml文件(安装新插件的情况下)获取的.在Eclipse3.0中,Registry API已经不被建议使用,对所有插件的注册信息的缓存已被重构为两部分,一是Bundle数据,另外是ExtensionRegistry API,它们分别从.bundledata或.state文件和.registry.X文件中获取.这三个文件是Eclipse生成的,它们的数据来源是各个插件的plugin.xml和MANIFEST.MF文件.当平台安装新的插件时,它们都将被重新生成.之所以从它们中而不是直接解析plugin.xml和MANIFEST.MF文件,是要Eclipse起动更快.
在Eclipse3.0中,有些插件文件夹下并没有MANIFEST.MF文件,这是为了兼容Eclipse以前版本的插件.对于每一个已被Eclipse3.0安装(installed)的插件(Bundle),系统都会生成一个MF文件在configuration\org.eclipse.osgi\manifests目录下(已经有MANIFEST.MF文件的插件除外).被生成的MF文件内容只是该插件的plugin.xml文件中扩展点外的部分数据.
关于作者：本文作者张增志，目前在中国北京先进数通信息技术有限公司工作，从事Java方面的开发和研究。
Email：zzz8067@hotmail.com
联系地址：北京市海淀区车道沟1号滨河大厦D座6层
邮编：100089
联系客服
