Equinox OSGi

1. 背景信息

Equinox项目是Eclipse开源组织提供的OSGi框架的实现。Eclipse自3.0版本开始，其内核移植到OSGi框架上。通过OSGi框架强大的组件控制，交互和管理能力，再加上Eclipse插件的自有特点，Eclipse开源框架得到了跳跃式的发展。同时，OSGi规范得益于Eclipse IDE环境庞大的使用者，OSGi联盟也进入了快速发展时期。

OSGi框架在2006年之前还不为广大的开发者所知，OSGi的开源框架实现也只有ObjectWeb上的Oscar和Knopflerfish两个实现。最初的OSGi标准主要应用于J2ME和J2SE，Equinox的加入使得OSGi标准的应用领域不断扩充，目前OSGi在J2EE方面的应用也在不断的发展中。IBM Websphere Application Server从6.0版本开始其内核转向由OSGi实现。

OSGi的本质是将Java面向对象的开发转向面向组件和服务的开发。OSGi框架提供了一套完善的机制用于管理和控制组件（Bundle）、服务（Service）的生命周期，以及组件和服务在其生命周期内的交互。

本文及后续系列文章将以Equinox项目为基础，讲述如何实现基于OSGi的应用。

2. Equinox项目概述

Equinox项目包括OSGi R4版本规范核心框架的实现，一系列OSGi标准服务Bundle及运行基于OSGi的系统的一些基础构件。用户可以直接访问该项目在Eclipse的网址Equinox获取概括性的信息。目前，关于Equinox的进展大部分资料及项目进展存在于Eclipse Wiki上。

目前，Equinox项目包括OSGi核心框架的实现，OSGi标准服务Bundle实现，OSGi的服务器端（J2EE实现）应用，Equinox部署更新框架及一些研究方向（未成熟发布的构想如JMX管理，安全管理，面向方面的设计与应用等）。

2.1OSGi核心框架的实现

Equinox的OSGi核心实现由三部分组成，包括：

Ø OSGi核心规范的实现（org.eclipse.osgi）

该项目是OSGi核心框架标准规范的实现。由于Eclipse在3.0版本之前未采用OSGi作为系统内核，所以，为了重用Eclipse3.0以前核心系统的代码，Equinox的OSGi实现在一定程度上显得比较繁冗。用户如果想研究开源的OSGi框架实现的源代码，可以从Oscar（目前为Apache的Felix项目）或Knopflerfish项目着手。ObjectWeb上的Oscar项目最初实现OSGi R2版本框架时，整个核心的源代码不超过40个类文件。现在，Oscar项目转由Apache维护，项目称之为Felix，目前已发布1.0版本。Knopflerfish也是很早实现OSGi的一个开源项目，该项目的网站上提供了很多关于OSGi编程的注意事项。

Ø OSGi框架启动支持（org.eclipse.equinox.launcher）

OSGi 框架启动支持对于Eclipse IDE开发环境熟悉的开发用户来说并不算陌生。使用Eclipse以前版本的用户会发现在Eclipse安装目录下有一个startup.jar的文件，该文件是Eclipse开发环境的入口程序封装。Equinox将该Jar文件的实现迁移为一个独立的OSGi Fragment。该Fragment主要是帮助Equinox建立起运行环境，如类加载路径，运行配置参数等等。

Ø Equinox启动可执行程序

Equinox启动可执行程序即为eclipse.exe文件，该执行程序并不是Eclipse以前版本的exe可执行文件，而是由原来的eclipse.exe程序拆分而来，该执行文件的一部分功能拆分为一个共享DLL，放置在OSGi框架启动支持段项目（org.eclipse.equinox.launcher）中，与原来的Eclipse根目录下的startup.jar文件功能合并。

2.2OSGi标准服务Bundle实现

OSGi在提出核心框架规范的同时为一些常用的服务如日志服务（LogService），配置管理服务（Config Admin），事件管理服务（Event Admin），HTTP服务（HTTP Service）等。Equinox提供了大部分OSGi标准服务的bundle的实现，同时，借助于Eclipse环境的一些自身的特点，Equinox在实现这些OSGi标准服务的同时，提供了很多功能扩展服务（如org.eclipse.equinox.common）。

Equinox项目目前提供的OSGi标准服务实现如下所示：

Equinox实现项目	服务名称	服务说明
org.eclipse.equinox.app	Application Container	该项目实现了OSGi R4 MEG中的应用程序容器服务
org.eclipse.equinox.common	Common Utility Bundle	由一组Eclipse工具类（如IStatus，Assert，IAdaptable等）组成的实用程序Bundle。该Bundle也可以在非OSGi环境中独立使用。
org.eclipse.equinox.device	Device Access Service	OSGi R4规范中的Device Access Service标准服务的实现，该组件由Prosyst公司提供实现。
org.eclipse.equinox.ds	Declarative Services	OSGi R4规范中的Declarative Service标准服务的实现，该组件由Prosyst公司提供实现
org.eclipse.equinox.event	Event Admin Service	OSGi R4规范中的事件管理服务的实现。
org.eclipse.equinox.http	HTTP Service	OSGi R4规范中的HTTP服务实现
org.eclipse.equinox.log	Log Service	OSGi R4规范中的日志服务实现
org.eclipse.equinox.metatype	Metatype Service	OSGi R4规范中的Metatype服务的实现
org.eclipse.equinox.preferences	Preferences Service	OSGi R4规范中的Preferences服务的实现
org.eclipse.equinox.registry	Extension Registry	Equinox提供的Ecipse扩展点（extension point）注册表服务
org.eclipse.equinox.supplement	Supplemental Bundle/JAR	Equinox提供的一组Equinox实现所使用的类型库
org.eclipse.equinox.useradmin	User Admin Service	OSGi R4规范中的用户管理服务实现
org.eclipse.equinox.wireadmin	Wire Admin Service	OSGi R4规范中的服务通信拓扑管理服务
org.eclipse.osgi.services	OSGi Services API	OSGi R4规范中的服务接口定义，该Bundle由OSGi联盟定义的服务API接口组成
org.eclipse.osgi.util	OSGi Utilities	OSGi R4规范中的工具类接口及接口实现Bundle

2.3OSGi的服务器端（J2EE实现）应用

Equinox实现了OSGi在J2ME、J2SE方面的应用的同时，也推动了OSGi在J2EE方面的应用。Equinox提供了一组基础的Bundle，使得使用JSP、Servlet和Struts等J2EE技术的Web应用项目可以运行于Equinox OSGi环境中。同样的，Equinox通过一组Bundle，可以将Equinox OSGi应用嵌入到现有的Web服务器（如Tomcat，Jetty等）和应用服务器（如Websphere，Weblogic等）中。

下面是Equinox在J2EE应用方面的一组Bundle列表：

Equinox J2EE实现项目	服务名称	服务说明
org.eclipse.equinox.http	HTTP service	该Bundle是OSGi R4规范中的HTTP服务的标准实现。目前该实现只支持Servlet 2.3。
org.eclipse.equinox.http.registry	HTTP registry	该Bundle支持使用Eclipse的扩展注册表注册servlet，文件资源和JSP而不是使用OSGi中的代码注册机制。
org.eclipse.equinox.servletbridge	Servlet Bridge	该Bundle提供一个底层的Hook servlet，使得Equinox可以嵌入到现有的应用服务器中运行。该Bundle中的servlet启动嵌入的Equinox并使其可以处理来自底层应用服务器接收的HTTP请求。
org.eclipse.equinox.http.servlet	HTTP Servlet	该Bundle为在Equinox中发布其他servlet处理引擎（如传统的应用服务器）为OSGi HTTP服务提供支持。
org.eclipse.equinox.http.servletbridge	HTTP ServletBridge	该Bundle为底层的应用服务器（如Tomcat，Jetty等）发布为OSGi HTTP服务提供一层封装。封装的应用服务器必须安装该servlet bridge。
javax.servlet	Servlet API	Servlet规范标准接口API的Bundle封装。
javax.servlet.jsp	Servlet JSP API	Servlet JSP API接口的Bundle封装。
org.mortbay.jetty	Jetty	嵌入式Jetty实现的Bundle封装。目前Equinox提供的Jetty实现版本为5.x。
org.eclipse.equinox.http.jetty	HTTP Jetty	该Bundle封装Jetty为标准的OSGI HTTP服务。目前该服务只能使用Jetty 5.x版本；如果用户希望使用Jetty 6.x版本的Bundle封装，可以参考ops4j上的实现。

关于如何在Equinox环境中部署Web应用（JSP、Servlet和Struts等），请参考Equinox网站相关资料。我会在本系列后续文档中给出详细介绍。

2.4Equinox部署更新框架（Provisioning）

Eclipse提供为插件的分组，更新及远程维护提供了一套完善的机制。用户可以通过远程更新站点安装或升级所需功能的插件。为了适应OSGi环境的特点，Equinox项目组为基于OSGi的系统的部署更新提供了一套全新的框架，称为“equinox p2”。目前该框架还在第一个发布版本的最后阶段，该功能预计将在Eclipse 3.4版本中集成发布。

2.5Equinox的最新研究方向

Ø 资源管理（Resource Monitoring）

该方向致力于为基于OSGi的系统提供一个轻量级的资源监控管理基础框架，该框架基于JMX技术。目前该研究方向已经提供了一套可供展示的基本实现。

Ø 安全管理

该方向致力于将Java安全机制（JCA/JAAS框架）集成到Eclipse中。为Eclipse/Equinox环境提供诸如消息摘要，数字签名，密钥存储，证书存储等基础安全机制。此外，该方向还为Eclipse提供JAVA包签名，Bundle加载时的签名校验，代码权限等机制的实现。

Ø 面向方面的开发

该方向致力于解决在OSGi环境中面向方面编程的一些技术问题，如加载编排和模块化等。

3. 结论与参考

本文简要概述了Equinox在OSGi规范方面的实现以及它为OSGi在其他领域的应用所做的研究。后续文档中，我们将会将上述各个方面展开进行详细的描述。OSGi的广泛应用将大大推动JAVA由面向对象的编程向面向组件和服务的编程转变。

目前，JCP组织提出JSR-291将OSGi纳入JAVA标准规范。如果该JSR最终被集成到J2SE实现中，开发人员可以在JAVA基础编程中直接采用OSGi提供动态的模块化应用。

Equinox项目源代码的位置位于CVS服务器上：:pserver:anonymous:dev.eclipse.org/cvsroot/eclipse路径下，以org.eclipse.equinox.*命名的项目以及该位置下的equinox-incubator目录下。

4. 插曲

SUN公司提出了一个类似于OSGi的模块化系统规范称之为“HK2”。HK2的全称为“Hundred Kilobytes Kernel”，包括Modules Subsytem和Component Model两部分。据称，该内核将在JDK 7中集成，同时，SUN在其开源的GlassFish J2EE应用服务器项目V3版本中将HK2作为其系统内核实现。

1、概述

在上文中讲到，Equinox包括核心框架，标准服务实现，面向J2EE的应用，新的部署更新框架及一些其他的研究方向。本文主要针对Equinox实现的OSGi核心框架及Equinox OSGi运行环境的搭建过程进行详细讲述。

用户在阅读下文时，应具有基本的Java编程及打包的概念并对OSGi标准的构成有一定的了解，理解OSGi框架及Bundle的概念。

2、OSGi核心框架

从OSGi核心框架示意图可以看到，OSGi核心框架主要包括模块层，生命周期层，服务层及安全层组成。完整的OSGi核心框架实现，还包括包管理服务（Package Admin）、启动层次服务（Start Level）、条件许可管理（Conditional Permission Admin）、权限管理（Permission Admin）及URL处理服务（URL Handlers）等框架服务。

关于OSGi核心框架的详细介绍请参考OSGi标准规范。

3、Equinox的OSGi Framework实现

Equinox的OSGi框架实现包含在org.eclipse.osgi插件项目中。在发布的Eclipse环境中，用户可以在Eclipse安装目录下的plugins目录中找到该插件。该插件一般以"org.eclipse.osgi_<版本号>.jar"的JAR文件形式打包。由于是从Eclipse3.0以前版本迁移到OSGi核心的缘故，目前的Equinox OSGi 实现中包含的代码非常繁杂。

在org.eclipse.osgi项目源代码中用户可以看到除了OSGi接口及框架实现外，还包括adaptor接口及默认的adaptor(defaultAdaptor)，eclipse adaptor(eclipseAdaptor)实现，控制台实现(console)，附加服务扩展(supplement)，Bundle组件解析(resolver)和Bundle JAR文件校验等功能。

在实际使用中，用户使用该Jar文件即可将OSGi框架运行起来（参考下文OSGi运行环境的搭建）。作为一个产品级的应用，往往存在很多系统级的参数可供用户进行配置以调整系统的运行行为而满足不同环境的要求。同样，Equinox运行环境也提供了大量的运行参数以供用户选择配置。配置Equinox运行环境参数的方式主要有两种，一种是使用JVM环境变量；另一种方式是使用Equinox的配置文件（config.ini）。

用户在获取到org.eclipse.osgi_<版本号>.jar文件后，可以尝试以命令行的方式启动该Jar文件。该Jar文件的入库主类是：org.eclipse.core.runtime.adaptor.EclipseStarter。

java -jar org.eclipse.osgi_3.3.1.R33x_v20070828.jar

用户会发现该程序执行后立即退出，控制台上没有任何输出。这是因为不存在拥有可持续运行的代码功能，框架启动后即退出主线程。下文中，我们会给出OSGi运行环境搭建的详细过程。

4、搭建Equinox OSGi运行环境

4.1 原始的OSGi环境

从Eclipse官方网站下载Equinox OSGi框架。将其下载到c:/equinox目录中。本文中使用的Equinox版本为3.3.1。直接从命令行运行该jar文件时程序执行后会立即退出，为了更好的了解Equinox OSGi框架的特点，我们在运行时添加JVM参数"osgi.console"。如下图所示：

执行"java -Dosgi.console -jar org.eclipse.osgi_3.3.1_R33x_v20070828.jar"后，系统给出"osgi>"命令输入提示。输入"ss"命令后回车，用户可以看到上图所示"Framework is launched."的信息。同时，下方显式了系统启动的Bundle列表，id列为该Bundle在OSGi运行环境中的唯一运行标识，State列为该Bundle当前的状态，Bundle列显示了该Bundle组件的SymbolicName。

此时，OSGi框架已经处于运行状态。

Equinox OSGi Console提供了很多命令用于与OSGi框架交互，用户可以输入任何非OSGi Console的内部命令字符，控制太将显示Equinox Console提供的所有命令。如下下图所示：

执行"services"命令，用户可以看到当前OSGi框架中发布的所有的服务信息。

4.2 以运行参数方式向OSGi环境中部署Bundle

下载Equinox SDK，将plugins目录下的org.eclipse.osgi.services_3.1.200.v20070605.jar文件拷贝到C:/equinox目录下。修改命令行运行参数如下：

java -Dosgi.console -Dosgi.bundles=org.eclipse.osgi.services_3.1.200.v20070605.jar -jar org.eclipse.osgi_3.3.1_R33x_v20070828.jar

执行该命令，系统运行结果如下图所示：

从运行结果可以看出，JVM参数"-Dosgi.bundles=org.eclipse.osgi.services_3.1.200.v20070605.jar"将org.eclipse.osgi.services组件部署到了OSGi运行环境中。此时，该组件的状态为"RESOLVED"，即该组件被框架解析但没有启动。如果用户希望组件在加载的同时启动该组件，可以修改上述参数为：

-Dosgi.bundles=org.eclipse.osgi.services_3.1.200.v20070605.jar@2:start。

"@2"指明该组件的启动级别，":"后的"start"标明该组件在加载后启动。按修改后的参数重新执行命令输出结果如下图所示：

从上图可以看出，部署的org.eclipse.osgi.services组件在加载后被OSGi框架启动，其状态显示为"ACTIVE"。

4.3以配置文件方式向OSGi环境中部署Bundle

从上述部署Bundle的方式看出，当部署多个Bundle时，使用JVM参数配置方式是不可取的。Equinox OSGi支持从配置文件中读取加载的Bundle，下面我们演示如何使用配置文件部署多个Bundle。

将Equinox SDK中plugins目录下的org.eclipse.osgi.util_3.1.200.v20070605.jar文件拷贝到C:/equinox目录下。

Equinox OSGi提供了环境变量"osgi.configuration.area"，该变量指明了配置文件config.ini的存储路径。下面我们在C:/equinox目录下添加config.ini文件，并在该文件中添加如下内容：

osgi.bundles=org.eclipse.osgi.services_3.1.200.v20070605.jar@2:start, org.eclipse.osgi.util_3.1.200.v20070605.jar

修改OSGi框架启动命令行为:

java -Dosgi.console -Dosgi.configuration.area=. -jar org.eclipse.osgi_3.3.1_R33x_v20070828.jar

执行上述命令后的输出结果如下图所示：

5、使用Eclipse Launcher启动Equinox OSGi

熟悉Eclipse IDE环境的用户会注意到3.2版本（包括3.2）以前Eclipse安装目录下存在eclipse.exe和startup.jar两个文件，用于启动Eclipse运行环境。从3.3版本开始，Equinox将startup.jar拆分为两个不同的Bundle（Fragment）放置在了plugins目录下。用户可以从Equinox站点下载Launcher。下载后的3.3.1发布版本的Launcher包括下面两个组件：

org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar

org.eclipse.equinox.launcher.win32.win32.x86_1.0.1.R33x_v20070828 [目录]

在进行下述操作之前，我们需要调整C:/equinox的目录结构，在该目录下添加"configuration"和"plugins"两个目录，将所有的Bundle组件（包括目录）转移到plugins目录下；将config.ini文件转移到configuration目录下，将Launcher包中的"eclipse.exe"文件拷贝到C:/equinox目录下。此时的目录结构如下图所示：

plugins目录下的内容如下图所示：

修改命令行OSGi框架启动命令为：

eclipse.exe -console -noexit

执行该命令后，在弹出的控制台中输入"ss"命令，输出结果如下：

5.1使用eclipse.ini文件

除了从命令行传入eclipse.exe使用的运行参数外，用户也可以配置与eclipse.exe的文件同名的ini文件存放eclipse.exe运行所需要的参数。用户应将该ini文件放置在eclipse.exe所在的文件目录下。

我们在C:/equinox目录下添加eclipse.ini文件，在该文件中添加如下内容：

-console

-noexit

直接点击eclipse.exe程序图标启动Equinox OSGi运行环境。程序运行结果如下图所示：

至此，Equinox OSGi完整的运行环境已经搭建完成。如果用户希望将新的Bundle发布到该环境中，只需要修改configuration目录下config.ini文件，将新的bundle添加到osgi.bundles参数下。

6、常见问题

用户在上述操作步骤中，会发现在configuration目录下生成一些错误日志文件，如果用户发现日志中出现以下内容：

java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:72)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447)
at org.eclipse.equinox.launcher.Main.run(Main.java:1173)

用户可以在config.ini文件中添加如下配置：

eclipse.ignoreApp=true

7、小结

在上文中，我们详细介绍了Equinox OSGi环境组成及其搭建过程。在下一篇文档中，我们会对Equinox OSGi的运行参数做详细的介绍，同时提供一种方式使得OSGi框架能够自动发现部署的OSGi bundle而不用频繁修改配置文件

1、概述

上文我们对Equinox OSGi运行环境的组成及搭建过程做了详细讲述。本文主要对Equinox OSGi运行环境的可配置参数及其作用加以介绍，从而使用户在实际使用过程中可以对Equinox运行环境更好地进行控制。

Equinox项目沿袭Eclipse的特点，具有高度的可配置性。用户可以通过命令行参数或系统属性参数（JVM属性参数）两种方式对Equinox OSGi运行环境进行设定。命令行参数可以看作是系统属性参数的简化方式，Equinox中提供的很多系统属性参数可能不具有对应的命令行快捷设定。

2、Equinox配置参数详解

Equinox配置的参数在实际使用中可以通过以下三种方式：

• 在命令行中，使用Java虚拟机参数-D作为系统属性来设定，如：-Declipse.ignoreApp=true；
• 在配置文件config.ini文件中进行配置，如：osgi.framework=plugins/org.eclipse.osgi_<版本号>.jar
• 在Eclipse Launcher的配置文件.ini文件中进行配置。在此配置文件中用户需要使用命令行参数而不是系统属性的格式。如：-console。用户在发布Equinox或RCP应用时可以设定启动程序（Eclipse Launcher）的名称和图标，如将启动程序改为：MyApp.exe，则对应的启动配置文件应命名为：MyApp.ini。

下表列举了Equinox3.3版本主要的配置参数。该列表包括系统参数，用于JVM属性配置或config.ini文件配置；命令行参数（如果有）用于.ini文件配置；参数的简要说明描述该参数的用途。

说明：

• 表中所列参数来自于Eclipse3.3帮助文档，关于参数的解释可能不够准确，请用户参考Eclipse帮助获取详细信息。
• 表中所列参数严格说来仅部分用于Equinox OSGi，全部适用于Eclipse。在下述说明中将不区分Equinox和Eclipse。

系统参数	命令行参数	参数说明
eclipse.activateRuntimePlugins		用于控制运行时（Runtime）插件的激活。如果RCP应用程序不需要使用运行时插件提供的服务，可以将该属性值设定为false，从而避免在系统启动时激活运行时插件。
eclipse.allowAppRelaunch		如果值为true，当当前运行的应用程序Application退出时，Equinox系统主线程会一直等待该应用的另一个应用被启动。如果停止system.bundle即Bundle ID值为0的Bundle，则会强制Equinox主线程停止等待另一个应用启动。该参数的默认值为false。
eclipse.application	-application	该Equinox系统所启动的应用程序的标识符。该参数值会覆盖eclipse.product系统属性中定义的应用程序。
eclipse.application.launchDefault		当系统启动时，该属性用于自动启动默认的Application应用。默认的应用通过eclipse.application或eclipse.product系统属性设定。该属性的默认值为"true"。如果该属性值设为false，当系统启动时不会自动启动默认的application，系统主线程会持续等待，直至一个application通过应用描述符服务（application descriptor service）启动。
eclipse.application.registerDescriptors		该属性控制所有安装的application是否注册相应的应用描述符服务。该属性的默认值为false。如果设定为false，只有默认的application在服务注册表中具有相应的应用描述符服务；如果设定为true，所有安装的application在OSGi服务注册表中都具有相应的应用描述符服务注册。
eclipse.commands		在启动Equinox系统时，使用该属性参数将用回车换行方式分隔的命令行参数列表传递给系统。
eclipse.consoleLog		如果该属性参数设定且值为true，则所有的日志输出都会传送到Java的System.out。该属性参数可以和-debug参数结合用于调试。
eclipse.debug.startupTime		该属性用于设定系统运行时Java虚拟机启动的时间（单位为毫秒）
eclipse.ee.install.verify		如果该属性值设定为true，在Bundle组件安装时，OSGi框架会检查框架运行所需要的运行环境。该参数默认值为false。
eclipse.exitOnError		该参数设定为true时，如果系统在运行时遇到无法处理的错误，则系统会退出。该参数默认值为true。
eclipse.ignoreApp		该参数设定为true时，系统主线程将不启动默认的application，同时停止并退出系统进程。该属性参数的默认值为false。 该参数不同于"eclipse.application.launchDefault"，系统主线程不会等待任何的应用描述符服务启动。
eclipse.log.backup.max		该参数用于设定允许备份的日志文件的最大数。如果备份的日志文件的数量达到该参数的设定值，则最早的日志文件将被删除。该参数的默认值为10，如果用户设定值小于或等于0，则系统启用默认值。
eclipse.log.size.max		每个日志文件的最大允许文件大小（单位：KB），该参数的默认值为“1000”。当日志文件达到允许的最大值时，日志文件会循环写入。如果该参数值被设定为0或负值，Equinox系统会使用默认值。
eclipse.noExtensionMunging		如果该参数值为 "true"，则遗留的注册扩展将会保留。默认情况下，这些扩展会更新为Eclipse3.0中的新的扩展点。
eclipse.noLazyRegistryCacheLoading {-noLazyRegistryCacheLoading}		如果该参数值为"true"，平台的插件注册表缓存加载优化将不被激活。默认情况下，配置项在需要的时候会从注册表缓存（如果存在）中加载，以提升性能。该参数如果值为true，系统启动时会强制加载所有注册表缓存信息。
eclipse.noRegistryCache	-noRegistryCache	如果该参数值为"true"，将不使用内部扩展注册缓存。
eclipse.pluginCustomization {-pluginCustomization}		保存默认插件配置的属性文件的文件路径。该属性文件中的配置项会覆盖主配置中的插件属性。如果该参数值为相对路径，则系统会认为路径相对于当前eclipse工作目录。
eclipse.product	-product	运行的产品标识。该参数控制各种产品定义信息和产品使用的application
eclipse.service.jobs		该参数控制org.eclipse.core.jobs插件是否注册为OSGi服务，如果值为"false"则不注册为OSGi服务
eclipse.service.pref		该参数控制org.eclipse.equinox.preferences插件是否注册为OSGi服务，如果值为"false"则不注册为OSGi服务
eclipse.startTime		该参数在Equinox启动时设定。该参数的值为System.currentTimeMillis()方法返回值的字符串表示。用户不需要设定该参数
eclipse.stateSaveDelayInterval		该参数为系统状态变更请求的序列化延迟间隔，单位毫秒，默认值为30000ms。该参数用于阻止系统管理操作（如安装Bundle组件）过程中产生的大量的磁盘写操作。
eclipse.vm	-vm	该参数指向系统启动所需的Java执行程序(JRE)的路径。如果不指定此项，则 JRE 位于 jre（它与Eclipse.exe 可执行文件位于同一目录）。此信息用于构造系统重启使用的命令行。
eclipse.vmargs	-vmargs	该参数用于配置系统启动所需的Java虚拟机参数。此信息用于构造系统重启使用的命令行。
osgi.adaptor		OSGi框架启动使用的框架适配（framework adaptor）的类名称
osgi.arch	-arch	定义 Eclipse 平台在其上运行的处理器体系结构。Eclipse 平台通常使用 Java os.arch 属性的常用值来计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getOSArch() 用于插件。示例值有：“x86”、“sparc”、“PA-RISC”和“ppc”。
osgi.baseConfiguration.area		当osgi.configuration.area参数未指定时，该参数用于指定基本的配置信息。
osgi.bundlefile.limit		该参数用于限定框架保持打开的Jar文件的数量。该参数允许的最小值为10，默认最大值不受限定。
osgi.bundles		以逗号分隔的bundle列表。该列表中的bundle在系统启动运行时，会自动安装并根据设定启动（可选）。每一个Bundle配置形式遵循下面的规范： [@ [] [":start"]] 如果忽略start-level (>0的整数)被忽略，则将该Bundle设定为默认的启动等级。如果"start"标记被设定，则该Bundle在安装后框架会启动该Bundle。"Simple bundle location"被解释为相对于框架所作路径的上一级目录。"start-level"标明该Bundle应该在哪一OSGi启动等级运行该Bundle，如果。"start-level"未被设定，则系统会自动为Bundle配置适当的默认启动级别。
osgi.bundles.defaultStartLevel		系统安装的所有的Bundle的启动级别。用户可以在osgi.bundles配置中为某一Bundle指定特定的启动等级。如果未设定Bundle的启动等级，则Bundle的启动等级为该参数设定值。该参数默认值为4。
osgi.compatibility.bootdelegation		如果该参数值为"true"，当一个类或资源查找不到时，类加载器会启动父类加载器进行最后的查找。该参数的默认值为"true"
osgi.compatibility.errorOnFailedStart		Bundle组件可以通过Bundle清单属性"Eclipse-LazyStart"或"Bundle-ActivationPolicy"标记自身的延迟激活策略。自OSGi R4.1规范开始，如果一个设定了延迟激活策略的Bundle启动失败，从该Bundle进行类加载必须仍然成功。在OSGi R4.1之前，Eclipse定义的延迟激活策略允许启动失败的Bundle抛出类加载异常。如果该属性设定为"true"，那么在启动失败的Bundle中加载类时将导致类加载错误；否则，仍然允许从启动失败的Bundle中加载类。 该参数的默认值为"true"
osgi.compatibility. eagerStart.LazyActivation		OSGi R4.1规范强制要求所有的Bundle，包括设定了延迟激活策略的Bundle，在允许激活前必须被标记为启动状态。规范添加了一个新方法Bundle.start(options)使得延迟激活的Bundle可以按照设定的延迟激活策略启动。 如果osgi.compatibility.eagerStart.LazyActivation设定为"true"，所有设定了延迟激活策略的组件会被自动标记为激活状态；否则，标记了延迟激活策略的组件必须通过Bundle.start(options)方法来启动。 该参数的默认值为"true"。
osgi.checkConfiguration		如果该参数值为"true"，系统会检查配置缓存的时间戳以保证缓存内容反映了安装的Bundle的最新配置。该参数默认值为"false"。
osgi.classloader.singleThreadLoads		如果该参数值为"true"，那么同一时间只能有一个线程允许加载类。默认值为"false"。该参数用于屏蔽可能引发死锁的虚拟机Bug。
osgi.clean		如果该参数值为"true"，系统在启动时，会清除OSGi框架及Eclipse运行时缓存的任何数据。该参数会清除Bundle依赖缓存和eclipse扩展注册缓存。适用该参数可以强制eclipse重新初始化上述缓存。
osgi.configuration.cascaded		如果该参数设定为"true"，该配置会级联到父配置。父配置通过osgi.sharedConfiguration.area参数设定。
osgi.configuration.area	-configuration	系统配置(默认为config.ini)的存储路径。
osgi.configuration.area.default		系统配置(默认为config.ini)的默认存储路径。该参数值只有在参数"osgi.configuration.area "未设定时适用。
osgi.console	-console [port]	如果该参数设定为一个非空值，系统会启用OSGi控制台。如果该参数的值是一个适当的整数，系统会将该值作为控制台监听用户输入的端口，同时也作为控制台的输出端口。
osgi.console.class		该参数用于设定运行的控制台实现的类名称。
osgi.console.encoding		该参数用于设定控制台输入与输出信息的编码方式。如果该参数未设定，系统默认使用虚拟机file.encoding属性的值，如果file.encoding属性未设定，则默认使用iso8859-1作为编码方式。
osgi.contextClassLoaderParent		OSGi框架使用的上下文类加载器的父类加载器类型，有效的类型包括： app - application classloader. boot -boot classloader. ext - extension classloader. fwk - framework classloader. ccl - 在框架启动时设定的原始的上下文类加载器（该参数的默认值）.
osgi.debug	-debug	将平台置于调试方式，并从给定位置处的文件装入调试选项（如果指定的话）。此文件指示哪些调试点可用于插件以及是否已启用它们。如果未给出文件位置，则平台在启动 eclipse 的目录中查找称为“.options”的文件。URL 和文件系统路径都可作为文件位置。
osgi.dev	-dev	将平台置于开发方式。将可选类路径条目（用逗号分隔的列表）添加至每个插件的运行时类路径。例如，当工作空间包含要开发的插件时，指定 -dev bin 会为每个插件项目的名为 bin 的目录添加类路径条目，允许在其中存储最新生成的类文件。除去了冗余或不存在的类路径条目。
osgi.filepermissions.command		该参数设定一个可选的操作系统命令用于设定抽取的本机代码的文件操作权限。在一些操作系统中，某些本机代码需要设定为可执行，可以使用此参数设定执行授权的命令。如UNIX类型的操作系统，用户可以使用如下代码设定某一可执行文件具有执行权限： osgi.filepermissions.command="chmod +rx [fullpath]" 此处[fullpath]用于指代实际的文件路径。
osgi.framework	-framework	OSGi框架实现的位置（URL格式）。如osgi.framework=file://d:/proxy/org.eclipse.osgi.jar
osgi.frameworkClassPath		该参数可以为OSGi框架指定一个以逗号分隔的类路径列表。如果设定类路径为相对路径，则系统认为相对于OSGi框架的所在路径（参考osgi.framework)。
osgi.framework.extensions		该参数用于指定框架扩展的Bundle列表。每一个Bundle遵循如下规则： 系统会在org.eclipse.osgi Bundle的父目录中查找Simple bundle location。框架扩展可以用来使用不同的框架适配来运行Eclipse。框架扩展可用包含一个eclipse.properties文件来设定系统属性。例如，一个提供了自定义框架适配实现的框架扩展可以使用osgi.adaptor属性参数设定其框架适配实现的类名称。
osgi.framework.shape		该属性设定Eclipse OSGi框架实现的形式。Eclipse启动时自动设定该属性，不需要用户配置。属性值"jar"表明框架实现包含在一个单一的Jar文件中；属性值"folder"表明框架实现包含在一个文件目录中。
osgi.framework.library.extensions		用逗号分隔的附加扩展类库文件查找列表。如果未设定此参数，则系统只使用System.mapLibraryName(String)方法返回的值作为查找路径。有些特定的系统允许一种以上的类库扩展，如AIX系统允许.a和.so类库文件扩展，而System.mapLibraryName(String)方法只返回.a的类库文件扩展。
osgiframeworkParentClassloader		OSGi框架类加载器的父类加载器类型，可用的类型包括： app - the application classloader. boot - the boot classloader. ext - the extension classloader. current - 加载equinox launcher的类加载器
osgi.framework.useSystemProperties		控制将框架属性设定为全局系统属性还是由每一个框架实例自行持有。默认情况（值为true）下框架属性也配置为系统属性。 该属性在同一个Java虚拟机中运行多个OSGi框架实例时，可让每个实例控制自己独立的属性配置。
osgi.hook.configurators		用逗号分隔的hook配置列表。如果设定了该配置参数，那么系统将只使用该列表中指定的hook配置。所有在hookconfigurators.properties文件中配置的hook将被忽略。
osgi.hook.configurators.include		用逗号分隔的附加hook配置列表。该参数可用于配置可选的hook配置，如果参数"osgi.hook.configurators"被设定，则该参数的值将被忽略。
osgi.hook.configurators.exclude		用逗号分隔的被排除的hook配置的列表。该参数可用于排除hookconfigurators.properties配置文件中配置的hook。如果参数"osgi.hook.configurators"被设定，则该参数的值将被忽略。
osgi.install.area	-install	平台的安装位置。该位置指明了Eclipse插件的位置，一般为eclipse目录下的plugins目录。
osgi.instance.area	-data	运行系统实例数据存储区。插件使用此位置存储其运行数据。默认情况下，用户可以在此参数下的.metadata目录及子目录中找到这些数据。该参数也是资源插件用来存储项目的位置，即工作空间Workspace。
osgi.instance.area.default		运行系统默认的实例数据存储区。系统中的插件使用此位置存储各自的运行数据。例如，资源插件使用该位置存储所有项目（即工作空间workspace）。该参数仅在配置参数"osgi.instance.area"未设定时启用。
osgi.locking		运行平台所使用的锁类型。可用的类型包括："java.io", "java.nio", 和 "none"。默认值为"java.nio"。如果JRE不支持"java.nio"，那么"java.io"将作为默认值。
osgi.manifest.cache		Bundle清单的生成和查找路径。Bundle清单缓存位置可以独立设定，默认为系统配置存储区。
osgi.nl	-nl	定义 Eclipse 平台在其上运行的语言环境的名称。Eclipse 平台通常自动计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getNL() 用于插件。示例值有：“en_US”和“fr_FR_EURO”。
osgi.nl.user		当用户在命令行添加-nl参数时，该属性设定locale的名称。
osgi.noShutdown	-noExit	如果值为"true"，当eclipse应用程序停止时，Java虚拟机并不退出。这在eclipse应用停止后检查OSGi框架非常有帮助。
osgi.os	-os	定义 Eclipse 平台在其上运行的操作系统。Eclipse 平台通常使用 Java os.name 属性的常用值来计算最佳设置。如果在此处指定该项，则这是 Eclipse 平台使用的值。此处指定的值可作为 BootLoader.getOS() 用于插件，并用于解析插件清单文件中提及的路径中 $os$ 变量的出现。示例值有：“win32”、“linux”、“hpux”、“solaris”和“aix”。
osgi.parentClassloader		框架中所有安装的Bundle的类加载器的父类加载器类型。可用的类型为： app - 应用程序类加载器. boot - 启动类加载器. ext - 扩展类加载器. fwk - 框架类加载器
osgi.requiredJavaVersion		运行Eclipse所要求的Java环境的最低版本。默认值为"1.4.1"。
osgi.resolverMode		对安装到框架中的Bundle的解析模式。设定值为"strict"时，框架将使用严格的解析模式。默认的解析模式是不严格的。当使用严格模式解析Bundle时，框架从标记了x-internal 或 x-friends标签的导出包中加载类或资源时使用更严格的访问限定。
osgi.sharedConfiguration.area		Eclipse平台运行时的共享配置存储区。如果参数"osgi.configuration.cascaded"设定为"true" ，该参数定义的共享配置存储区内的配置将作为根配置。
osgi.splashLocation		运行系统时，启动屏幕（.bmp文件）的URL绝对路径。该属性会覆盖"osgi.splashPath"属性的设定值。
osgi.splashPath		用逗号分隔的URL，该URL指向一个名为"splash.bmp"的文件。该属性会被配置参数"osgi.splashLocation"设定的任何值覆盖。
osgi.startLevel		框架的启动级别，默认启动级别为6。
osgi.support.signature.verify		用逗号分隔的Bundle签名校验策略。可选的策略包括： certificate - 启用证书解析和校验。 trust - 启用证书信任校验，该策略在"certificate"策略之上。 runtime - 在运行时校验签名的Bundle组件的内容。该策略在"certificate"策略之上。 all -等同于"certificate,trust,runtime"。 true - 等同于"all"。当框架启动时设定。"osgi.support.signature.verify"参数的默认值。
osgi.syspath		指定Eclipse OSGi框架(org.eclipse.osgi)实现的存储路径，如"/eclipse/plugins"。该属性在Eclipse平台启动时由系统设定，不需要用户配置。
osgi.user.area	-user	用户数据的存储位置。该位置特定于操作系统用户，与Eclipse安装位置无关，可用于存储用户配置数据。
osgi.user.area.default		用户数据的默认存储位置。该位置特定于操作系统用户，与Eclipse安装位置无关，可用于存储用户配置数据。该属性只在参数"osgi.user.area"未设定时使用。
osgi.ws	-ws	该参数设定窗口系统类型，如win32, motif, ...

3、其他命令行参数

说明：下述参数仅用于3.3以上版本

• --launcher.ini (Executable) NEW

.ini文件的位置。如果不指定，系统会在执行程序的相同位置查找与执行程序相同名称且扩展名为.ini的文件。如eclipse.exe会查找eclipse.ini，product.exe会查找product.ini。

• --launcher.suppressErrors (Executable) NEW

如果指定该参数，启动程序将不显示任何错误或消息窗口。

• -name NEW

当应用程序启动后，在任务中显示的程序名称。如果未设定，将显示.exe的名称。

• -noSplash (版本1.0+)

是否显示启动屏幕

• -showSplash (Executable, Main) NEW

指定启动屏幕使用的bitmap文件。如果设定了该参数，Equinox Launcher会在启动Java虚拟机之前显示启动屏幕。如果未指定，虚拟机启动后Main入口会查找参数osgi.splashLocation 和 osgi.splashPath 设定的启动屏幕文件。

• -startup (Executable) NEW

启动eclipse使用的jar文件的位置。该jar文件的MANIFEST.MF文件中中应设定Main-Class属性的值为：org.eclipse.equinox.launcher.Main。如果该参数未设定，Launcher会在plugins目录下查找版本号最大的org.eclipse.equinox.launcher组件。

4、launcher.ini文件格式举例

Equinox launcher.ini文件的命令行参数设定格式如下例所示：

-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Xms40m
-Xmx256m