产品扩展

可以通过编写产品扩展来扩展 Liberty 的功能。

可以编写您自己的 Liberty 功能部件,并将其安装到现有 Liberty 服务器,也可以将它们打包以交付给用户。

Liberty 提供各种可用来扩展运行时环境的系统编程接口 (SPI);您也可以使用更多高级功能,例如,以编程方式从 Java™ 应用程序操作 Liberty 服务器。

产品扩展

产品扩展是磁盘上的目录,它的结构类似于 Liberty 安装目录 ${wlp.install.dir}。它通过 ${wlp.install.dir}/etc/extensions 目录中名为 extension-name.properties 的文件定义到 Liberty 安装过程中。随后使用产品扩展目录的内容来扩展 Liberty。可将多个产品扩展一起安装,但是它们必须具有唯一名称;这可通过为属性文件命名来强制实施。缺省产品扩展位置 ${wlp.user.dir}/extension 不需要属性文件;此位置下的内容是自动检测到的,并且运行时将其识别为“usr”产品扩展。

产品扩展通常包含一个或多个 Liberty 功能部件,但是可以具有任何用于扩展 Liberty 环境的内容(例如,脚本或资源)。

最佳实践: 将产品扩展安装到不受 Liberty 环境更新影响的目录。有关更多信息,请参阅应用服务或升级时可修改那些内容?
图 1.
此图显示 Liberty 安装,此安装包含两个功能部件:“Supergui”和“App Services”
产品扩展文件具有下列属性:
com.ibm.websphere.productId=your_product_id
com.ibm.websphere.productInstall=absolute_or_relative_file_path
注: 如果使用了相对文件路径,那么它必须是 ${wlp.install.dir} 值的对等项。
例如:
com.ibm.websphere.productId=org.acme.supergui
com.ibm.websphere.productInstall=supergui/wlp-ext

功能部件

Liberty 功能部件包含一个定义文件(功能部件清单)和一组 OSGi 捆绑软件,这些捆绑软件提供对应 Liberty 运行时环境中特定功能的类和服务。

使用 Liberty 功能部件取代常规应用程序的场景

在一些场景中,将功能实现为 Liberty 功能部件,而不是实现为应用程序,可能比较合适。以下列表描述了使用功能部件的一些优势:
  • 通过功能部件管理器配置来控制功能部件,因此功能部件独立于用户应用程序管理。
  • 通过功能部件代码可以访问 Liberty SPI,后者允许与运行时环境进行更深层次的集成。
  • 功能部件可以从 server.xml 文件接收用户指定的配置,并且可以在开发工具中公开其配置设置,而不必更改开发工具。
  • 功能部件可以轻松地将类和服务提供给彼此以及提供给用户应用程序。
  • 功能部件可以非常轻,不含任何应用程序容器依赖性。
  • 功能部件可以用来扩充特定编程模型。例如,用户功能部件可以对 OSGi 应用程序编程模型添加对于定制 Blueprint 名称空间处理程序或 Blueprint 注释的支持。
注: 功能部件通常无法直接移植到其他应用程序服务器;如果可移植性很重要,请使用符合规范的应用程序。

在服务器中使用功能部件

要在 Liberty 服务器中使用用户编写的功能部件,必须将该功能部件安装到产品扩展目录。这可以是预定义的“用户产品扩展”位置,也可以是位于 Liberty 安装目录外部的扩展。然后,您可以将功能部件名称添加到服务器配置。

用户产品扩展是服务器在其中查找其他功能部件的预定义目录。必须将功能部件定义 .mf 文件复制到 ${wlp.user.dir}/extension/lib/features 目录,并且必须将捆绑软件 .jar 文件复制到 ${wlp.user.dir}/extension/lib 目录。

会按照添加产品功能部件的相同方式,将用户编写的功能部件添加到服务器配置。作为产品扩展一部分的功能部件必须以扩展名称为前缀,以避免与其他提供程序的功能部件产生名称冲突。对于 usr/extension/lib 目录中的功能部件,缺省前缀为 usr:

例如,如果已将称为 simple-1.0 的功能部件安装到 ${wlp.user.dir}/extension/lib 目录,那么必须将该功能部件配置到 server.xml,如下所示:
<featureManager>
    <feature>usr:simple-1.0</feature>
</featureManager>
如果已在您自己的位置安装名为 myFeature 的功能部件,并且已在 ${wlp.install.dir}/etc/extensions/myExt.properties 文件中定义了产品扩展,那么必须将该功能部件配置到 server.xml 文件中,如下所示:
<featureManager>
    <feature>myExt:myFeature</feature>
</featureManager>

当您启动服务器时,功能部件管理器会检测到该功能部件,而且捆绑软件会安装到 OSGi 框架并启动。

另请参阅添加和移除 Liberty 功能部件功能部件管理

以程序化方式从应用程序使用功能部件

功能部件可以将类和服务提供给应用程序。

要提供 Java 类以供应用程序使用,必须在功能部件清单的 IBM-API-Package 头中列出类包。在 IBM-API-Package 头中列出类包可使这些类对于应用程序类装入器可视。可通过 API 可视性类型来控制 API 包的可视性。请参阅为 Liberty 功能部件项目指定 API 和 SPI 包

要允许 OSGi 应用程序使用服务,必须在功能部件清单的 IBM-API-Service 头中列出这些服务。功能部件提供 OSGi 服务,以便您能以程序化方式从应用程序引用这些服务。

必须向 OSGi 服务注册表 (SR) 注册服务,以允许应用程序(或其他功能部件)找到这些服务。OSGi 应用程序和其他功能部件可从 SR 执行直接查询,也可以使用 Blueprint 或 OSGi 声明式服务之类的功能来插入其服务依赖关系。Java EE 应用程序更有可能通过 JNDI 来查找服务;在 Liberty 中,联合了 SR 和 JNDI,从而允许 Java EE 应用程序使用 JNDI 在 SR 中查找服务。有关更多信息,请参阅使用 OSGi 服务注册表

将功能部件作为 Web 应用程序来提供

要将 Liberty 功能部件提供为 Web 应用程序,您可以将功能部件中的 OSGi 捆绑软件发布为 Web 应用程序捆绑软件 (WAB)。除了捆绑软件所需要的 OSGi 头以外,您还可以使用 Web-ContextPath 头来指定 Web 应用程序上下文路径。

例如:

Web-ContextPath: myWABapp
Bundle-ClassPath: WEB-INF/classes

配置插入和处理

使用功能部件的主要好处在于,用户在 server.xml 文件(以及所包括的文件)中可以轻松配置这些功能部件。配置文件由 Liberty 内核进行监视和解析,而且每次更改配置文件时,产生的属性集可以插入相关组件中。

Liberty 配置由内核中的 OSGi 配置管理 (CA) 服务管理,而且可以根据该规范来访问。配置属性集由持久存储的身份 (PID) 加以标识,而 PID 用于将 server.xml 文件中的元素与注册用来接收属性的组件相关联。

例如,如果您使用 com.acme.console 的 PID 向 CA 服务注册您的功能部件,那么用户可以在 server.xml 文件中指定以下配置:
<com.acme.console color="blue" size="17"/>
而且您的功能部件将接收属性:
  • color="blue"
  • size="17"

(可选)您可以提供使用 OSGi 元类型描述符来描述配置属性的元数据。使用描述符会导致将配置元数据包含在 Liberty 所生成且由开发者工具使用的配置模式中,因此在应用程序开发者配置其服务器时,将自动向其呈现配置属性。

有关接收和描述配置属性的更多详细信息,请参阅启用服务来接收配置数据

Liberty 中的声明式服务

更大或更复杂的功能部件往往受益于使用 OSGi 声明式服务 (DS) 来让功能部件由多项服务组成,以及管理依赖性和配置属性的插入。使用 DS 允许延迟激活服务,延迟装入 Java 类直到使用服务,以及根据依赖性对服务激活进行排序。Liberty 产品中的大多数功能部件由 DS 管理。

另请参阅 使用 OSGi 声明式服务来编写高级功能部件


用于指示主题类型的图标 概念主题

文件名:cwlp_prod_ext.html