JBoss EAP 7 是一款适用于 Jakarta EE Web 配置文件和 Jakarta EE 平台规格的 Jakarta EE 8 兼容实施。

有关 Jakarta EE 8 的详情，请参阅 关于 Jakarta EE。

Jakarta EE 定义不同的配置文件。每个配置集是一个 API 子集，表示适合特定类应用程序的配置。

Jakarta EE 8 定义 Web 配置文件和平台配置文件的规格。产品可以选择以任何组合实施平台、Web 配置文件或一个或多个自定义配置文件。

JBoss EAP 7.4 是兼容 Web 配置文件和完整平台规范的 Jakarta EE 8 实施。

如需 Jakarta EE 8 API 的完整列表，请参阅 Jakarta EE 规范。

Apache Maven 是 Java 应用程序开发中使用的分布式构建自动化工具，用于创建、管理和构建软件项目。Maven 使用名为 Project Object Model 或 POM 文件的标准配置文件来定义项目并管理构建流程。poms 描述模块和组件依赖项，使用 XML 文件描述生成的项目打包和输出的构建顺序和目标。这可确保以正确、一致的方式构建项目。

Maven 使用存储库可实现此目的。Maven 存储库存储 Java 库、插件和其他构建构件。默认公共存储库是 Maven 2 Central Repository，但存储库可以是私有和内部存储库，目标为在开发团队之间共享通用工件。也可从第三方获取存储库。JBoss EAP 包括一个 Maven 存储库，其中包含 Jakarta EE 开发人员通常用于在 JBoss EAP 上构建应用程序的许多要求。若要将项目配置为使用此存储库，请参阅 配置 JBoss EAP Maven 存储库。

有关 Maven 的更多信息，请参阅 Welcome to Apache Maven。

如需有关 Maven 存储库的更多信息，请参阅 Apache Maven Project - 存储库简介。

Project Object Model 或 POM 文件是 Maven 用于构建项目的配置文件。这是一个 XML 文件，其中包含项目的信息以及如何构建项目，包括源位置、测试和目标目录的位置、项目依赖项、插件存储库及其可执行的目标。它还可以包含有关项目的其他详细信息，包括版本、描述、开发人员、邮件列表、许可证等。pom.xml 文件需要一些配置选项，并将默认为所有其他选项。

pom.xml 文件的 schema 可以在 http://maven.apache.org/maven-v4_0_0.xsd 找到。

有关 POM 文件的更多信息，请参阅 Apache Maven Project POM 参考。

Maven POM 文件的最低要求

pom.xml 文件的最低要求如下：

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.jboss.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1</version>
</project>

Maven settings.xml 文件包含 Maven 的特定用户配置信息。它包含的信息不得通过 pom.xml 文件分发，如开发人员身份、代理信息、本地存储库位置，以及特定于用户的其他设置。

有两个位置可以找到 settings.xml ：

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <profiles>
    <!-- Configure the JBoss EAP Maven repository -->
    <profile>
      <id>jboss-eap-maven-repository</id>
      <repositories>
        <repository>
          <id>jboss-eap</id>
          <url>file:///path/to/repo/jboss-eap-7.4.0-maven-repository/maven-repository</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-eap-maven-plugin-repository</id>
          <url>file:///path/to/repo/jboss-eap-7.4.0-maven-repository/maven-repository</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
  <activeProfiles>
    <!-- Optionally, make the repository active by default -->
    <activeProfile>jboss-eap-maven-repository</activeProfile>
  </activeProfiles>
</settings>

settings.xml 文件的 schema 可在 http://maven.apache.org/xsd/settings-1.0.0.xsd 找到。

存储库管理器是一种可让您轻松管理 Maven 存储库的工具。存储库管理器在多个方面很有用：

有关 Maven 存储库管理器的更多信息，请参阅 最佳实践 - 使用存储库管理器。

常用的 Maven 存储库管理器

按照以下步骤下载和安装 Maven：

您可以使用任一方法下载 JBoss EAP Maven 存储库：

您可以使用在线可用的 JBoss EAP Maven 存储库，或者使用列出的任一方法之一下载并安装到本地：

使用 Maven 设置配置 JBoss EAP Maven 存储库

这是推荐的方法。与共享服务器上的存储库管理器或存储库一起使用的 Maven 设置提供更好的项目的控制和可管理性。设置还支持使用替代镜像将特定存储库的所有查找请求重定向到存储库管理器，而不更改项目文件。有关镜像的详情请参考 http://maven.apache.org/guides/mini/guide-mirror-settings.html。

这种配置方法适用于所有 Maven 项目，只要 POM 文件不包含存储库配置。

本节论述了如何配置 Maven 设置。您可以配置 Maven 安装全局设置或用户的安装设置。

使用 Project POM 配置 JBoss EAP Maven 存储库

如果您决定使用项目 POM 文件配置存储库，您必须仔细规划。Transitively POM 是这类配置的问题，因为 Maven 必须查询外部存储库查找缺少的工件，这会减慢构建过程。它还可能导致您失去对工件来自哪里的控制。

确定 JBoss EAP 存储库的 URL

存储库 URL 取决于存储库所在的位置。您可以将 Maven 配置为使用以下任一存储库位置：

构建应用程序并将其部署至红帽 JBoss 企业应用平台所需的构件和依赖关系托管在公共存储库中。构建应用程序时，您必须指示 Maven 使用此存储库。如果您计划使用 Red Hat CodeReady Studio 构建和部署应用，本节将介绍配置 Maven 的步骤。

Maven 随 Red Hat CodeReady Studio 一起发布，因此不需要单独安装。但是，您必须配置 Maven，以供 Java EE Web 项目向导使用，以部署到 JBoss EAP。以下流程演示如何通过从 Red Hat CodeReady Studio 编辑 Maven 配置文件来配置 Maven 以用于 JBoss EAP。

JBoss EAP Maven 存储库现在已配置为与红帽 CodeReady Studio 搭配使用。

这部分论述了在红帽 JBoss 企业应用平台上对材料(BOM)POM 的使用情况。

BOM 是一个 Maven pom.xml (POM)文件，用于指定模块的所有运行时依赖项的版本。版本依赖项列在 文件的依赖项管理部分中。

项目使用 BOM，方法是将其 groupId:artifactId:version (GAV)添加到项目的 pom.xml 文件的依赖项管理部分，并指定 <scope>import</scope> 和 <type>pom</type> 元素值。

支持的 Maven Artifacts

作为产品构建流程的一部分，JBoss EAP 的所有运行时组件都是从受控环境中的源代码构建的。这有助于确保二进制工件不包含任何恶意代码，并且它们在产品的生命周期内得到支持。这些工件可以通过 -redhat 版本限定符（如 1.0.0-redhat-1 ）轻松识别。

将受支持的构件添加到构建配置 pom.xml 文件可确保构建使用正确的二进制构件来进行本地构建和测试。请注意，带有 -redhat 版本的构件不一定是受支持的公共 API 的一部分，将来的修订可能会改变。有关公共支持的 API 的详情，请查看发行版中包含的 Javadoc 文档。

例如，要使用受支持的 Hibernate 版本，请在构建配置中添加类似如下的内容：

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-core</artifactId>
  <version>5.3.1.Final-redhat-1</version>
  <scope>provided</scope>
</dependency>

请注意，上例中包含 <version/> 字段的值。不过，建议您使用 Maven 依赖项管理来配置依赖项版本。

依赖项管理

Maven 包括管理整个构建过程中直接和传递依赖关系版本的机制。有关使用依赖项管理的一般信息，请参阅 Apache Maven 项目： 依赖机制简介。

在您的构建中直接使用一个或多个支持的红帽依赖关系不能保证所有构建的传递依赖项都会被完全支持。Maven 构建通常使用来自 Maven 中央存储库和其他 Maven 存储库的构件源组合。

JBoss EAP Maven 存储库中包含了依赖性管理 BOM，用于指定所有支持的 JBoss EAP 二进制构件。此 BOM 可以在构建中使用，以确保 Maven 将受支持的 JBoss EAP 依赖项的优先级放在构建中的所有直接和传递依赖关系上。换句话说，传输依赖关系将管理到正确的受支持的依赖版本（若适用）。此 BOM 的版本与 JBoss EAP 版本匹配。

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>eap-runtime-artifacts</artifactId>
      <version>7.4.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>

JBoss EAP Jakarta EE Specs BOM

jboss-jakartaee-8.0 BOM 包含 JBoss EAP 使用的 Jakarta EE 规范 API JAR。

要在项目中使用此 BOM，请首先在 POM 文件的 dependencyManagement 部分中添加 jboss-jakartaee-8.0 BOM 依赖项，为 groupId 指定 org.jboss.spec，然后添加应用所需特定 API 的依赖项。这些依赖项不需要版本，并使用 提供 的范围，因为 jboss-jakartaee-8.0 BOM 中包含了这些 API。

以下示例使用 jboss-jakartaee-8.0 BOM 的 1.0.0.Alpha1 版本添加 Servlet 和 Jakarta 服务器页面 API 的依赖项。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.jboss.spec</groupId>
      <artifactId>jboss-jakartaee-8.0</artifactId>
      <version>1.0.0.Alpha1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.jboss.spec.javax.servlet</groupId>
    <artifactId>jboss-servlet-api_4.0_spec</artifactId>
    <scope>provided</scope>
  </dependency>
  <dependency>
    <groupId>org.jboss.spec.javax.servlet.jsp</groupId>
    <artifactId>jboss-jsp-api_2.3_spec</artifactId>
    <scope>provided</scope>
  </dependency>
  ...
</dependencies>

JBoss EAP BOMs 可用于应用程序开发

下表列出了可用于应用程序开发的 Maven BOMs。

以下示例使用 jboss-eap-jakartaee8 BOM 的 7.4.0.GA 版本。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>jboss-eap-jakartaee8</artifactId>
      <version>7.4.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <scope>provided</scope>
  </dependency>
  ...
</dependencies>

JBoss EAP 客户端 BOM

客户端 BOMs 不创建依赖项管理部分或定义依赖项。相反，它们是其他 BOM 的聚合，用于打包远程客户端用例所需的一组依赖项。

wildfly-ejb-client-bom、wildfly-jms-client -bom 和 wildfly-jaxws-client-bom 由 jboss-eap-jakartaee8 BOM 管理，因此您无需管理项目依赖项中的版本。

以下是如何将 wildfly-ejb-client-bom、wildfly- jms-client-bom 和 wildfly-jaxws-client-bom 依赖项添加到项目的示例：

<dependencyManagement>
  <dependencies>
    <!-- JBoss stack of the Jakarta EE APIs and related components.  -->
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>jboss-eap-jakartaee8</artifactId>
      <version>7.4.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
  ...
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.jboss.eap</groupId>
    <artifactId>wildfly-ejb-client-bom</artifactId>
    <type>pom</type>
  </dependency>
  <dependency>
    <groupId>org.jboss.eap</groupId>
    <artifactId>wildfly-jms-client-bom</artifactId>
    <type>pom</type>
  </dependency>
  <dependency>
    <groupId>org.jboss.eap</groupId>
    <artifactId>wildfly-jaxws-client-bom</artifactId>
    <type>pom</type>
  </dependency>
  ...
</dependencies>

有关 Maven 依赖项和 BOM POM 文件的更多信息，请参阅 Apache Maven Project - 依赖机制简介。

JBoss EAP 使用模块化类加载系统来控制已部署应用的类路径。这个系统比传统的分层类加载器系统提供更多灵活性和控制力。开发人员对其应用可用的类有精细的控制，并且可以配置部署来忽略应用服务器提供的类，而非自有的类。

模块类加载器将所有 Java 类划分为称为模块的逻辑组。每个模块可以定义对其他模块的依赖关系，以便将该模块中的类添加到其自己的类路径中。由于每个部署的 JAR 和 WAR 文件都被视为模块，因此开发人员可以通过在其应用中添加模块配置来控制其应用的类路径的内容。

为了进行类加载，JBoss EAP 将所有部署视为模块。它们称为动态模块。根据部署类型，类加载行为会有所不同。

Subdeployment 模块（如 EAR 中的 WAR 和 JAR 部署）对父模块具有自动依赖关系。但是，它们之间没有自动依赖关系。这称为子部署隔离，可以为每个部署或整个应用服务器禁用。

子部署模块之间的显式依赖关系可以通过与任何其他模块相同的方法添加。

JBoss EAP 模块类加载程序使用优先级系统来防止类加载冲突。

在部署期间，会为每个部署及其各个依赖项创建完整的软件包和类列表。该列表根据类加载优先级规则排序。在运行时加载类时，类加载程序会搜索此列表，并加载第一个匹配项。这可以防止部署类路径中的相同类和软件包的多个副本相互冲突。

类加载器按照以下顺序加载从高到低的顺序：

jboss-deployment-structure.xml 文件是 JBoss EAP 的可选部署描述符。此部署描述符可对部署中的类加载进行控制。

此部署描述符的 XML 架构位于 EAP_HOME/docs/schema/jboss-deployment-structure-1_2.xsd 下的产品安装目录中。

可使用此部署描述符执行的关键任务有：

您可以以编程方式查找或加载应用程序代码中的类和资源。您选择的方法取决于多个因素。本节介绍可用的方法，并提供了有关何时使用它们的指导。

建议使用三个参数签名来以编程方式加载类。通过此签名，您可以控制您是否希望在加载时初始化目标类。获取和提供类加载器也更高效，因为 JVM 不需要检查调用堆栈来确定要使用的类加载程序。假设包含代码的类名为 CurrentClass，您可以使用 CurrentClass .class.getClassLoader（） 方法获取类 loader。

以下示例提供了类加载程序来加载并初始化 TargetClass 类：

Class<?> targetClass = Class.forName("com.myorg.util.TargetClass", true, CurrentClass.class.getClassLoader());

JBoss 模块库为迭代所有部署资源提供了多个 API。JBoss 模块 API 的 Java 文档位于以下位置 ：http://docs.jboss.org/jbossmodules/1.3.0.Final/api/.要使用这些 API，您必须在 MANIFEST.MF 中添加以下依赖项：

Dependencies: org.jboss.modules

务必要注意，尽管这些 API 提供了更大的灵活性，但它们的运行也比直接路径查找慢得多。

本节介绍了您可以编程化地迭代应用程序代码中的资源的一些方法。

企业存档(EAR)不作为单一模块加载，如 JAR 或 WAR 部署。它们作为多个唯一模块载入。

以下规则决定了 EAR 中存在的模块：

存在对非 WAR 子部署的隐式依赖关系，因为 JBoss EAP 默认禁用子部署类加载器隔离。无论子部署类加载器隔离如何，对父模块的依赖关系都会保留。

如果需要严格兼容性，则可启用 Subdeployment 类加载器隔离。这可以在单个 EAR 部署或所有 EAR 部署中启用。Jakarta EE 规范建议，便携式应用不应依赖于子部署相互访问，除非在每个子部署的 MANIFEST.MF 文件中明确声明依赖项为 Class-Path 条目。

企业存档(EAR)中的每个子部署是一个具有自己的类加载器的动态模块。默认情况下，子部署可以访问其他子部署的资源。

如果子部署不允许访问其他子部署的资源，则可以启用严格的子部署隔离。

此任务演示了如何在 EAR 部署中使用特殊的部署描述符在 EAR 部署中启用子部署类加载器隔离。这不需要对应用服务器进行任何更改，也不会影响任何其他部署。

现在，为这个 EAR 部署启用了 Subdeployment 类装载程序隔离。这意味着，EAR 的子部署不会对每个非 WAR 子部署具有自动依赖项。

JBoss EAP 提供配置企业存档(EAR)在 EAR 中包含的 WAR 模块子部署之间共享会话的功能。默认情况下禁用此功能，必须在 EAR 的 META-INF/jboss-all.xml 文件中明确启用。

要在 EAR 中启用 WAR 之间的会话共享，您需要在 EAR 的 META -INF/jboss-all.xml 中声明 shared- session-config 元素：

<jboss xmlns="urn:jboss:1.0">
  ...
  <shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
  </shared-session-config>
  ...
</jboss>

shared-session-config 元素用于为 EAR 中的所有 WAR 配置共享会话管理器。如果存在 shared-session-config 元素，则 EAR 内的所有 WAR 将共享相同的会话管理器。此处所做的更改将影响 EAR 中包含的所有 WAR。

<jboss xmlns="urn:jboss:1.0">
    <shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
    	<distributable/>
        <max-active-sessions>10</max-active-sessions>
        <session-config>
            <session-timeout>0</session-timeout>
            <cookie-config>
                <name>JSESSIONID</name>
                <domain>domainName</domain>
                <path>/cookiePath</path>
                <comment>cookie comment</comment>
                <http-only>true</http-only>
                <secure>true</secure>
                <max-age>-1</max-age>
            </cookie-config>
            <tracking-mode>COOKIE</tracking-mode>
        </session-config>
        <replication-config>
            <cache-name>web</cache-name>
            <replication-granularity>SESSION</replication-granularity>
        </replication-config>
    </shared-session-config>
</jboss>

下表列出了自动添加到部署中的模块，这些模块作为依赖项和触发依赖项的条件。

有关所含模块的完整列表以及是否被支持，请参阅红帽客户门户网站 中的 Red Hat JBoss Enterprise Application Platform 7 包含的模块。

JBoss LogManager 支持以下日志记录框架：

JBoss LogManager 支持以下 API：

JBoss 日志管理器还支持以下 SPI：

JBoss Logging 是包含在 JBoss EAP 中的应用程序日志框架。它提供了一种向应用添加日志的简便方法。您可以向应用添加代码，以使用框架以定义的格式发送日志消息。当应用部署到应用服务器时，服务器可以捕获这些消息，并根据服务器的配置显示或写入到 文件中。

JBoss Logging 提供以下功能：

此流程演示了如何使用 JBoss Logging 向应用添加日志。

以下示例从属性文件加载应用的自定义配置。如果未找到指定的文件，则会记录 aERROR 级别的日志消息。

import org.jboss.logging.Logger;
public class LocalSystemConfig
{
   private static final Logger LOGGER = Logger.getLogger(LocalSystemConfig.class);

   public Properties openCustomProperties(String configname) throws CustomConfigFileNotFoundException
   {
      Properties props = new Properties();
      try
      {
         LOGGER.info("Loading custom configuration from "+configname);
         props.load(new FileInputStream(configname));
      }
      catch(IOException e) //catch exception in case properties file does not exist
      {
         LOGGER.error("Custom configuration file ("+configname+") not found. Using defaults.");
         throw new CustomConfigFileNotFoundException(configname);
      }

      return props;
   }
}

您可以使用 Apache Log4j2 API 而不是 Apache Log4j API 将应用程序日志记录消息发送到您的 JBoss LogManager 实施。

您可以通过在项目的 pom.xml 文件中包含 Log4j2 API，在应用程序中使用 Log4j2 LogManager。另外，您必须在项目的 pom.xml 文件中包括对应的 Log4j2 LogManager 版本。

要为应用配置每个部署日志记录，请将 logging.properties 配置文件添加到您的部署中。建议使用这个配置文件，因为它可以用于任何记录 facade，其中 JBoss 日志管理器是底层日志管理器。

添加配置文件的目录取决于部署方法。

配置 logging.properties

服务器引导时使用 logging.properties 文件，直到 logging 子系统启动为止。如果您的配置中没有包括 logging 子系统，则服务器将此文件中的配置用作整个服务器的日志记录配置。

JBoss 日志管理器配置选项

如需更多信息，请参阅 JBoss EAP 配置指南中 的日志处理程序属性。

以下示例显示了记录到控制台的 logging.properties 文件的最小配置。

# Additional logger names to configure (root logger is always configured)
# loggers=

# Root logger level
logger.level=INFO

# Root logger handlers
logger.handlers=CONSOLE

# Console handler configuration
handler.CONSOLE=org.jboss.logmanager.handlers.ConsoleHandler
handler.CONSOLE.properties=autoFlush
handler.CONSOLE.autoFlush=true
handler.CONSOLE.formatter=PATTERN

# Formatter pattern configuration
formatter.PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.PATTERN.properties=pattern
formatter.PATTERN.pattern=%K{level}%d{HH:mm:ss,SSS} %-5p %C.%M(%L) [%c] %s%e%n

应用指定要在其 MANIFEST.MF 文件中使用的日志配置集。

若要添加日志配置文件到应用，可编辑 MANIFEST.MF 文件。

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <archive>
      <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
    </archive>
  </configuration>
</plugin>

部署应用时，它将将指定的日志记录配置文件中的配置用于其日志消息。

有关如何使用它配置日志配置文件和应用的示例，请参阅 JBoss EAP 配置指南中 的日志配置文件配置示例。

JBoss Logging Tools 是一种 Java API，支持日志消息、异常消息和通用字符串的国际化和本地化。除了提供转换机制外，JBoss 日志工具还为每一日志消息提供唯一标识符支持。

国际化的消息和异常是作为使用 org.jboss.logging.annotations 注解标注的接口内的方法定义创建的。实施接口是不需要的；JBoss 记录工具在编译时可以做到这一点。定义之后，您可以使用这些方法记录消息或获取代码中的异常对象。

通过为每个捆绑包创建属性文件（包含特定语言和区域的翻译），JBoss Logging 工具创建的国际化日志记录和异常接口可以本地化。JBoss Logging Tools 可以为每个捆绑包生成模板属性文件，然后可由转换器编辑。

JBoss Logging Tools 为您项目中的每个相应翻译属性文件创建每个捆绑包的实施。您要做的只是使用捆绑包中定义的方法，JBoss Logging Tools 可确保为您的当前区域设置调用正确的实施。

消息 ID 和项目代码是每个日志消息前面的唯一标识符。可以在文档中使用这些唯一标识符，以方便查找日志消息的相关信息。通过适当的文档，日志消息的含义可以从标识符确定，无论消息所写所用的语言是什么。

JBoss Logging 工具包括对以下功能的支持：

JBoss EAP 附带的 logging-tools 快速入门是一个简单的 Maven 项目，提供 JBoss Logging 工具的许多功能的有效示例。以下代码示例取自 logging-tools quickstart。

客户端实施与远程命名实施类似，但基于使用 Undertow HTTP 客户端的 HTTP。

连接管理是隐式而非直接的，使用与现有远程命名实施中使用的缓存方法。连接池根据连接参数进行缓存。如果指定超时期间不使用它们，则会丢弃它们。

要将远程 JNDI 客户端应用程序配置为使用 HTTP 传输，您必须在 HTTP 传输实现上添加以下依赖关系：

<dependency>
    <groupId>org.wildfly.wildfly-http-client</groupId>
    <artifactId>wildfly-http-naming-client</artifactId>
</dependency>

要执行 HTTP 调用，您必须使用 http URL 方案，并包含 HTTP 调用器的上下文名称 wildfly-services。例如：如果您使用 remote+http://localhost:8080 作为目标 URL，为了使用 HTTP 传输，您必须将其 更新为 http://localhost:8080/wildfly-services。

服务器端实施与现有的远程命名实施类似，但具有 HTTP 传输。

要配置服务器，您必须在 undertow 子系统中使用的每个虚拟主机上启用 http-invoker。这在标准配置中默认启用。如果禁用，您可以使用以下管理 CLI 命令重新启用它：

/subsystem=undertow/server=default-server/host=default-host/setting=http-invoker:add(http-authentication-factory=myfactory, path="/wildfly-services")

http-invoker 属性采用两个参数：默认为 /wildfly-services 的路径 和 http-authentication-factory，必须是 Elytron http-authentication-factory 的 引用。

会话复制可确保集群中节点的故障切换不会破坏可分布式应用的客户端会话。群集中的每个节点共享有关持续会话的信息，并在节点消失时接管会话。

会话复制是 mod_cluster、mod_jk、mod_proxy、ISAPI 和 NSAPI 集群提供高可用性的机制。

若要利用 JBoss EAP 高可用性(HA)功能并启用 Web 应用的集群，您必须将应用配置为可分布。如果您的应用未标记为 distributable，则永远不会分发其会话。

使应用程序可分发

<replication-granularity> 参数决定复制数据的粒度。它默认为 SESSION，但可以设置为 ATTRIBUTE，以提高大多数属性保持不变的会话的性能。

<replication-granularity> 的有效值可以是 ：

不可变会话属性

对于 JBoss EAP 7，会话更改或会话的任何可变属性访问时会触发会话复制。会话属性会被假定为可变，除非以下条件之一为 true：

通过减少通过网络发送的字节数或保留到存储的字节数，最小化单个会话属性的复制或持久性有效负载可能会直接提高性能。通过使用 web 应用程序，您可以使用以下方法优化会话属性的总结：

externalizer 实施 org.wildfly.clustering.marshalling.Externalizer 接口，用于指定类的 marshalling。外部化器不仅会直接从对象读取或写入输入/输出流，还执行以下操作：

传递是 控制内存使用情况的过程，方法是从内存中移除相对未使用的会话，同时将其存储在持久存储中。

激活 是在从持久存储中检索到传递的数据并重新放入内存中时。

在 HTTP 会话生命周期的不同时间进行传递：

如果活跃会话的数量超过可配置的最大值，则将传递会话。

会话始终使用最早使用(LRU)算法进行传递。

HTTP 会话传递是在应用的 WEB-INF/jboss-web.xml 和 META-INF/jboss-web.xml 文件中配置 的。

<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd">

   <max-active-sessions>20</max-active-sessions>
</jboss-web>

<max-active-sessions> 元素指定允许的最大活跃会话数，用于启用会话引用。如果会话创建将导致活跃会话数超过 <max-active-sessions>，则会话管理器已知的最旧的会话将传递，以便为新会话腾出空间。

mod_cluster-manager 应用是一个管理网页，可在 Apache HTTP 服务器中使用。它用于监控连接的 worker 节点并执行各种管理任务，如启用或禁用上下文，以及在集群中配置 worker 节点的负载平衡属性。

探索 mod_cluster-manager 应用

mod_cluster-manager 应用可用于在工作程序节点上执行各种管理任务。

图 - mod_cluster 管理网页

distributable-web 子系统可以配置为使用 HotRod 协议将 Web 会话数据存储在远程红帽数据网格群集中。在远程集群中存储 Web 会话数据可让缓存层独立于应用服务器进行扩展。

配置示例：

[standalone@embedded /]/subsystem=distributable-web/hotrod-session-management=ExampleRemoteSessionStore:add(remote-cache-container=datagrid, cache-configuration=__REMOTE_CACHE_CONFIG_NAME__, granularity=ATTRIBUTE)
{
    "outcome" => "success"
}

本例中使用的属性和可能的值有：

Jakarta Contexts 和 Dependency Injection 2.0 是一种规范，旨在使 Jakarta 企业 Bean 3 能够用作 Jakarta 服务器 Faces 管理 Bean。Jakarta Contexts 和 Dependency Injection 统一了两种组件模型，并可显著简化 Java 中基于 Web 的应用程序的编程模型。有关 Jakarta 上下文和依赖注入 2.0 的详细信息，请参阅 Jakarta 上下文和依赖注入 2.0 规范。

JBoss EAP 包括 Weld，它是一个 Jakarta 上下文和依赖注入 2.0 兼容规范。

Jakarta 上下文和依赖注入的好处

Jakarta 上下文和依赖注入的好处包括：

Bean 存档的默认 bean 发现模式被 标注。此类 Bean 存档 被认为是隐式 Bean 存档。

如果 注解 了 bean 发现模式，则：

Bean 定义注解

Bean 类可以具有一个 定义注解的 Bean，以便能够将其放置在应用程序中的任何位置，如 bean 存档中所定义。Bean 类中带有 Bean 定义注解，这被认为是隐式 Bean。

Bean 定义注解集合包含：

如果在 Bean 类上声明其中一个注释，则 bean 类被认为具有 Bean 定义注释。

@Dependent
public class BookShop
        extends Business
        implements Shop<Book> {
    ...
}

排除过滤器由 bean 归档的 beans.xml 文件中的 <exclude> 元素定义为 <scan> 元素的 子项。默认情况下，排除过滤器处于活动状态。如果 exclude 过滤器包含以下内容，则 exclude 过滤器将变为不活跃：

如果过滤器活跃，则该类型不在发现中，且：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">

    <scan>
        <exclude name="com.acme.rest.*" /> 1

        <exclude name="com.acme.faces.**"> 2
            <if-class-not-available name="javax.faces.context.FacesContext"/>
        </exclude>

        <exclude name="com.acme.verbose.*"> 3
            <if-system-property name="verbosity" value="low"/>
        </exclude>

        <exclude name="com.acme.ejb.**"> 4
            <if-class-available name="javax.enterprise.inject.Model"/>
            <if-system-property name="exclude-ejbs"/>
        </exclude>
    </scan>

</beans>

您可以使用注入来添加或更改现有代码的功能。

以下示例为现有类添加了转换功能，并假定您已有一个 Welcome 类，它具有方法 buildPhrase。buildPhrase 方法将城市名称用作参数，并输出一个短语，如"Welcome to Boston!"。

这个示例将假设的转换 器 对象注入到 Welcome 类中。Translator 对象可以是 Jakarta Enterprise Beans 无状态 Bean 或其他类型的 bean，它可以将句子从一个语言转换为另一种语言。在这个示例中，转换 器用于 转译整个问候语，而不修改原始 Welcome 类。Translator 在调用 buildPhrase 方法之前注入。

public class TranslatingWelcome extends Welcome {

    @Inject Translator translator;

    public String buildPhrase(String city) {
        return translator.translate("Welcome to " + city + "!");
    }
    ...
}

限定符是注解，用于避免在容器可以解析多个 Bean 时产生模糊的依赖关系，它们适合注入点。在注入点上声明的限定符提供一组合格的 Bean，后者声明相同的限定符。

限定条件必须以保留和目标声明，如下例所示。

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Synchronous {}

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Asynchronous {}

@Synchronous
public class SynchronousPaymentProcessor implements PaymentProcessor {
   public void process(Payment payment) { ... }
}

@Asynchronous
public class AsynchronousPaymentProcessor implements PaymentProcessor {
   public void process(Payment payment) { ... }
}

'@Any'

每当 bean 或注入点没有明确声明限定符时，容器会假定限定符 @Default。您不时需要声明一个注入点而无需指定限定符。这也有限定条件。所有 beans 都具有限定符 @Any。因此，通过在注入点显式指定 @Any，您可以抑制默认限定符，而不限制有资格注入的 Bean。

当您想迭代某个 Bean 类型的所有 bean 时，这尤其有用。

import javax.enterprise.inject.Instance;
...

@Inject

void initServices(@Any Instance<Service> services) {

   for (Service service: services) {

      service.init();

   }

}

每个 bean 都具有限定符 @Any，即使它没有明确声明此限定符。

每个事件也都有限定符 @Any，即使它不是明确声明这个限定符的。

@Inject @Any Event<User> anyUserEvent;

@Any 限定符允许注入点引用所有 bean 或特定 bean 类型的所有事件。

@Inject @Delegate @Any Logger logger;

您可以使用限定符解决模糊注入问题。阅读有关 Ambiguous 或 Unsatisfidened 依赖项 模糊注入的更多信息。

以下示例模糊不清，并且有两个 Welcome 实施 ， 一种是转换，另一个是没有实现。需要指定注入以使用转换 Welcome。

public class Greeter {
  private Welcome welcome;

  @Inject
  void init(Welcome welcome) {
    this.welcome = welcome;
  }
  ...
}

使用 Qualifier 解析 Ambiguous Injection

受管 Bean 是 Java 类。对于 Jakarta EE，受管 Bean 的基本生命周期和语义按照 Jakarta Managed Beans 1.0 规范 进行定义。您可以通过注解 beanagedBean 类来明确声明受管 Banaged Bean，但在上下文和依赖注入中，您不需要这样做。根据规范，上下文和依赖注入容器将满足以下条件的任何类视为受管 Bean：

受管 Bean 的无限制 Bean 类型包含 Bean 类、每个超级类，以及它直接或间接实施的所有接口。

如果受管 Bean 具有公共字段，则必须具有默认范围 @Dependent。

@Vetoed

您可以对类进行处理，从而不会安装本课程定义的 beans 或观察方法：

@Vetoed
public class SimpleGreeting implements Greeting {
    ...
}

在这个代码中，SimpleGreeting Bean 不视为注入。

软件包中的所有 bean 可以被禁止注入：

@Vetoed
package org.sample.beans;

import javax.enterprise.inject.Vetoed;

此代码在 org.sample .beans 软件包中的 package-info. java 代码将阻止此软件包中的所有 bean 注入。

Jakarta EE 组件（如无状态 Jakarta Enterprise Beans 或 Jakarta RESTful Web Services 资源端点）可以标记为 @Vetoed，以防止它们被视为 bean。将 @Vetoed 注释添加到所有持久实体可防止 BeanManager 将实体作为 Jakarta 上下文和依赖注入 Bean 管理。当实体使用 @Vetoed 标注时，不会进行注入。其背后的原因是防止 BeanManager 执行可能导致 Jakarta Persistence 供应商中断的操作。

如果在应用程序中检测到上下文和依赖注入组件，则上下文和依赖注入会自动激活。如果要自定义配置使其与默认值不同，您可以在部署存档中包含 META-INF/beans.xml 文件或 WEB-INF/beans.xml 文件。

将对象注入其他对象

将对象注入 Bean 时，所有对象的方法和属性都可用于您的 Bean。如果您注入到 bean 的构造器中，则调用 bean 的构造器时会创建注入对象的实例，除非注入引用已存在的实例。例如，如果在会话生命周期内注入会话范围 Bean，则不会创建新的实例。

使用 @Named 注解配置 Bean 名称

制作者方法 是一种充当 bean 实例来源的方法。如果指定的上下文中没有实例，方法声明本身会描述 bean，容器调用获取 bean 实例的方法。制作者方法使应用可以完全控制 bean 实例化流程。

本节介绍如何使用制作者方法生成各种不是注入 Bean 的不同对象。

示例中的 @Preferred 注释是限定符注释。有关 限定符 的更多信息，请参阅质量。

@SessionScoped
public class Preferences implements Serializable {
   private PaymentStrategyType paymentStrategy;
   ...
   @Produces @Preferred
   public PaymentStrategy getPaymentStrategy() {
       switch (paymentStrategy) {
           case CREDIT_CARD: return new CreditCardPaymentStrategy();
           case CHECK: return new CheckPaymentStrategy();
           default: return null;
       }
   }
}

以下注入点具有与 producer 方法相同的类型和限定注释，因此它会使用常见的上下文和依赖注入规则解析为制作者方法。容器调用制作者方法来获取实例来为这个注入点提供服务。

@Inject @Preferred PaymentStrategy paymentStrategy;

@Produces @Preferred @SessionScoped
public PaymentStrategy getPaymentStrategy() {
   ...
}

@Produces @Preferred @SessionScoped
public PaymentStrategy getPaymentStrategy(CreditCardPaymentStrategy ccps,
                                          CheckPaymentStrategy cps ) {
   switch (paymentStrategy) {
      case CREDIT_CARD: return ccps;
      case CHEQUE: return cps;
      default: return null;
   }
}

如果您将请求作用域 Bean 注入会话范围制作者中，则制作者方法会将当前的请求作用范围实例提升到会话范围中。这几乎肯定不是所需的行为，因此，以这种方式使用制作者方法时要谨慎。

借助制作者方法，您可以注入非 Bean 对象并动态更改代码。

您可以使用备用 Bean 来覆盖现有的 Bean。它们可以想象成是插入同一角色的类的方法，但功能不同。默认情况下禁用它们。

此任务显示如何指定和启用替代方案。

覆盖 Injection

此任务假定项目中已有一个 TranslatingWelcome 类，但您想要使用"mock" TranslatingWelcome 类覆盖它。测试部署就是如此，因此无法使用 真实的转换器 Bean。

现在，使用替代的实现而不是原始实施。

无需考虑，注释就会变得模糊不清。此任务向您展示如何使用强制减少杂乱情况并简化代码。

@Secure
@Transactional
@RequestScoped
@Named
public class AccountManager {
  public boolean transfer(Account a, Account b) {
    ...
  }
}

定义和使用 Stereotypes

public class AccountManager {
  @Inject Event<Withdrawal> event;

  public boolean transfer(Account a, Account b) {
    ...
    event.fire(new Withdrawal(a));
  }
}

public class AccountManager {
  @Inject @Suspicious Event <Withdrawal> event;

  public boolean transfer(Account a, Account b) {
    ...
    event.fire(new Withdrawal(a));
  }
}

public class AccountObserver {
  void checkTran(@Observes Withdrawal w) {
    ...
  }
}

您可以使用限定符来仅观察特定类型的事件。

public class AccountObserver {
  void checkTran(@Observes @Suspicious Withdrawal w) {
    ...
  }
}

在交易开始阶段之前或之后，交易处理接收事件通知。事务处理在有状态对象模型中很重要，因为状态通常保留比单个原子交易更长的时间。

交易有五种类型：

以下观察方法刷新应用程序上下文中缓存的查询结果集，但只有在更新 Category 树的操作成功时才会刷新：

public void refreshCategoryTree(@Observes(during = AFTER_SUCCESS) CategoryUpdateEvent event) { ... }

假设您缓存了 Jakarta Persistence 查询结果，请在应用程序范围中设置，如下例所示：

import javax.ejb.Singleton;
import javax.enterprise.inject.Produces;

@ApplicationScoped @Singleton

public class Catalog {
   @PersistenceContext EntityManager em;
   List<Product> products;
   @Produces @Catalog
   List<Product> getCatalog() {
      if (products==null) {
         products = em.createQuery("select p from Product p where p.deleted = false")
            .getResultList();
      }
      return products;
   }
}

有时 会创建 或删除产品。发生这种情况时，您需要刷新 产品 目录。但是，您必须等待事务成功完成，然后才能进行此刷新。

以下是创建和删除 Products 触发事件的 bean 示例：

import javax.enterprise.event.Event;

@Stateless

public class ProductManager {
   @PersistenceContext EntityManager em;
   @Inject @Any Event<Product> productEvent;
   public void delete(Product product) {
      em.delete(product);
      productEvent.select(new AnnotationLiteral<Deleted>(){}).fire(product);
   }

   public void persist(Product product) {
      em.persist(product);
      productEvent.select(new AnnotationLiteral<Created>(){}).fire(product);
   }
   ...
}

Catalog 现在可在成功完成事务后观察事件：

import javax.ejb.Singleton;

@ApplicationScoped @Singleton
public class Catalog {
   ...
   void addProduct(@Observes(during = AFTER_SUCCESS) @Created Product product) {
      products.add(product);
   }

   void removeProduct(@Observes(during = AFTER_SUCCESS) @Deleted Product product) {
      products.remove(product);
   }

}

Jakarta Contexts 和 Dependency Injection 可以简化拦截器代码，更轻松地应用于您的业务代码。

如果没有 Jakarta 上下文和依赖注入，拦截器有两个问题：

使用 Jakarta 上下文和依赖注入的 Interceptors

拦截器按照列出的顺序应用。

本节开发两个在服务存档(.sar)中打包在一起的 MBean 服务示例。

ConfigServiceMBean 接口声明了具体的方法，如 start、getTimeout 和 stop 方法，以正确 启动、保留 和停止 MBean，而无需使用任何 JBoss 特定类。ConfigService 类实施 ConfigServiceMBean 接口，从而实施该接口内使用的方法。

PlainThread 类扩展 ServiceMBeanSupport 类，并实施 PlainThreadMBean 接口。PlainThread 启动线程并使用 ConfigServiceMBean.getTimeout（） 来确定线程应休眠的时长。

package org.jboss.example.mbean.support;
public interface ConfigServiceMBean {
    int getTimeout();
    void start();
    void stop();
}
package org.jboss.example.mbean.support;
public class ConfigService implements ConfigServiceMBean {
    int timeout;
    @Override
    public int getTimeout() {
        return timeout;
    }
    @Override
    public void start() {
        //Create a random number between 3000 and 6000 milliseconds
        timeout = (int)Math.round(Math.random() * 3000) + 3000;
        System.out.println("Random timeout set to " + timeout + " seconds");
    }
    @Override
    public void stop() {
        timeout = 0;
    }
}

package org.jboss.example.mbean.support;
import org.jboss.system.ServiceMBean;
public interface PlainThreadMBean extends ServiceMBean {
    void setConfigService(ConfigServiceMBean configServiceMBean);
}

package org.jboss.example.mbean.support;
import org.jboss.system.ServiceMBeanSupport;
public class PlainThread extends ServiceMBeanSupport implements PlainThreadMBean {
    private ConfigServiceMBean configService;
    private Thread thread;
    private volatile boolean done;
    @Override
    public void setConfigService(ConfigServiceMBean configService) {
        this.configService = configService;
    }
    @Override
    protected void startService() throws Exception {
        System.out.println("Starting Plain Thread MBean");
        done = false;
        thread = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    while (!done) {
                        System.out.println("Sleeping....");
                        Thread.sleep(configService.getTimeout());
                        System.out.println("Slept!");
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
        thread.start();
    }
    @Override
    protected void stopService() throws Exception {
        System.out.println("Stopping Plain Thread MBean");
        done = true;
    }
}

jboss-service.xml 描述符演示了 ConfigService 类如何使用注入标签 注入 PlainThread 类。inject tag 在 PlainThreadMBean 和 ConfigServiceMBean 之间建立一个依赖关系，因此 PlainThreadMBean 可以轻松地使用 ConfigServiceMBean。

<server xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd"
        xmlns="urn:jboss:service:7.0">
 <mbean code="org.jboss.example.mbean.support.ConfigService" name="jboss.support:name=ConfigBean"/>
 <mbean code="org.jboss.example.mbean.support.PlainThread" name="jboss.support:name=ThreadBean">
  <attribute name="configService">
   <inject bean="jboss.support:name=ConfigBean"/>
  </attribute>
 </mbean>
</server>

编写 MBeans 示例后，您可以将类和 jboss-service.xml 描述符打包在服务存档(.sar)的 META-INF/ 文件夹中。

事务由两个或多个操作组成，它们都必须成功或全部失败。成功的结果是提交，失败的结果为回滚。在回滚中，每个成员的状态在尝试提交之前恢复为其状态。

设计良好的事务的典型标准是原子、一致、隔离和可达(ACID)。

ACID 是缩写词，代表 原子性、一致性、隔离 和持久性。此术语通常用于数据库或事务操作。

在使用 JBoss EAP 进行事务处理方面，交易量和事务管理器 ™ 大多可以互换。交易审核员这一术语通常用于分布式 JTS 交易。

在 Jakarta Transactions 事务中，TM 在 JBoss EAP 内运行，并在两阶段提交协议期间与交易参与者通信。

TM 告知事务参与者是提交还是回滚其数据，具体取决于其他交易参与者的结果。这样，它会确保事务遵循 ACID 标准。

交易参与者是指交易中能够提交或回滚状态的任何资源。它通常是数据库或 Jakarta 消息传递代理，但通过实施交易界面，应用程序代码也可以充当交易参与者。交易的每个参与者均独立决定是否提交或回滚其状态，并且只有在所有参与者都能够提交整个交易成功时才可行。否则，每位参与者都会回滚其状态，整个交易都会失败。TM 协调提交或回滚操作，并确定事务的结果。

Jakarta Transactions 是 Jakarta EE Spec 的一部分。它在 Jakarta Transactions 1.3 规范 中定义。

Jakarta Transactions 的实施通过 TM 实施，TM 由 Narayana 项目针对 JBoss EAP 应用服务器进行介绍。TM 允许应用程序通过单一全球交易分配各种资源，如数据库或 Jakarta 消息传递代理。全局事务被称为 XA 事务。通常具有 XA 功能的资源包含在此类交易中，但非 XA 资源也可以成为全球交易的一部分。有几个优化可帮助非 XA 资源作为 XA 功能资源的行为。如需更多信息，请参阅单阶段提交LRCO 优化。

在本文档中，术语 Jakarta Transactions 指的是两个方面：

TM 在 Jakarta Transactions 事务模式中工作，数据在内存中共享，事务上下文由远程 Jakarta Enterprise Beans 调用传输。在管理事务模式中，通过发送通用对象请求代理架构(CORBA)消息和 IIOP 调用传输事务上下文来共享数据。两种模式都支持在多个 JBoss EAP 服务器之间进行事务分发。

JTS 是对象交易服务(OTS)到 Jakarta 的映射。Jakarta EE 应用使用 Jakarta Transactions 来管理事务。然后，当交易经理切换到 JTS 模式时，Jakarta Transactions 与对象事务服务事务实施交互。JTS 工作于 IIOP 协议。使用 JTS 的事务管理器使用称为对象请求代理(ORB)的进程相互通信，使用称为通用对象请求代理架构(CORBA)的通信标准。如需更多信息，请参阅 JBoss EAP 配置 指南中的 ORB 配置。

从应用角度使用 Jakarta Transactions 时，JTS 事务的行为方式与 Jakarta Transactions 交易相同。

XML 交易服务(XTS)组件支持在业务交易中协调私有和公共 Web 服务。通过使用 XTS，您可以以受控且可靠的方式协调复杂业务交易。XTS API 支持基于 WS-Coordination、WS-Atomic Transaction 和 WS-Business Activity 协议的事务协调模型。

/subsystem=xts:write-attribute(name=async-registration, value=true)

XA 代表 eXtended 架构，由 X/Open Group 开发以定义使用多个后端数据存储的交易。XA 标准描述了全局 TM 和本地资源管理器之间的接口。XA 允许多个资源（如应用服务器、数据库、缓存和消息队列）参与同一事务，同时保留所有四个 ACID 属性。四个 ACID 属性中有一个是原子性，这意味着，如果其中一个参与者未能提交更改，其他参与者中止交易，并将其状态恢复为与交易发生前相同的状态。XA 资源是可参与 XA 全球交易的资源。

XA 事务是可跨越多个资源的事务。它涉及一个协调 TM，与一个或多个数据库或其他事务资源一起涉及单一全球 XA 事务。

TM 实施 X/Open XA 规范并支持跨多个 XA 资源进行 XA 事务。

XA 恢复是确保更新或回滚受交易进程影响的所有资源的过程，即使任何资源属于交易参与者崩溃或不可用。在 JBoss EAP 范围内，事务 子系统为使用它们的任何 XA 资源或子系统（如 XA 数据源、Jakarta 消息传递消息队列和 Jakarta Connectors 资源适配器）提供了 XA 恢复机制。

XA 恢复发生，无需用户干预.如果 XA 恢复失败，日志输出中会记录错误。如果需要帮助，请联系红帽全球支持服务。XA 恢复过程由定期恢复线程驱动，该线程默认每两分钟启动一次。定期恢复线程处理所有未完成事务。

XA 恢复有以下限制：

两阶段提交(2PC)协议引用一种算法来确定事务的结果。2PC 由事务管理器(TM)驱动，作为完成 XA 事务的过程。

第 1 阶段：准备

在第一阶段，交易参与者通知交易协调员是他们可以提交交易还是必须回滚。

第 2 阶段：提交

在第二阶段，交易协调员决定整个交易应提交或回滚。如果任一参与者无法提交，交易必须回滚。否则，事务可以提交。协调会指示有关要做什么的资源，他们在完成此操作时通知协调员。此时，事务已完成。

为了保持原子性并遵循用于事务的 ACID 标准，事务的某些部分可以长时间运行。事务参与者在提交时需要锁定作为队列中数据库表或消息一部分的 XA 资源。TM 需要等待每个交易参与者回听，然后才能指示他们全部提交或回滚。硬件或网络故障可能会导致资源被无限期锁定。

事务超时可以与事务关联，以控制其生命周期。如果在事务提交前通过超时阈值或回滚，超时会导致自动回滚事务。

您可以为整个事务子系统配置默认超时值，或者您可以禁用默认超时值并根据每个事务指定超时。

分布式事务是指与多个 JBoss EAP 服务器上的参与者进行的一项交易。JTS 规范要求 JTS 事务能够分布到来自不同供应商的应用程序服务器中。Jakarta Transactions 没有定义，但 JBoss EAP 支持 JBoss EAP 服务器中的分布式 Jakarta Transactions 事务。

对象请求代理(ORB)是一个向交易参与者、投资者、资源和其他跨多个应用服务器分发的其他服务发送和接收消息的过程。ORB 使用标准化接口描述语言(IDL)来通信和解释消息。通用对象请求代理架构(CORBA)是 JBoss EAP 中 ORB 使用的 IDL。

使用 ORB 的主要服务类型是分布式 Jakarta Transactions 系统，采用 JTS 规范。其他系统，特别是传统系统，可以选择使用 ORB 进行通信，而非其他机制，如远程 Jakarta Enterprise Beans 或 Jakarta 企业 Web 服务或 Jakarta RESTful Web 服务。

ORB 可移植性 API 提供了与 ORB 交互的机制。此 API 提供了获取对 ORB 引用的方法，以及将应用置于侦听来自 ORB 的传入连接的模式中。API 中的部分方法不受所有 ORB 支持。在这些情况下，会抛出异常。

API 由两个不同的类组成：

有关 ORB Portability API 中包含的方法和属性的详细信息，请参阅 红帽客户门户 上的 JBoss EAP Java 文档捆绑包。

JBoss EAP 交易经理(TM)包括多个优化功能，供您的应用利用：

优化有助于在特定情况下增强两阶段提交协议。通常，TM 会启动全局事务，该事务通过两阶段提交。但在某些情况下，当您优化这些事务时，TM 不需要进行完整的 2 阶段提交，因此进程速度更快。

下面详细介绍了 TM 使用的不同优化。

单阶段提交(1PC)

尽管交易时常遇到 2 阶段提交协议(2PC)，但在某些情况下不要求或无法满足这两个阶段。在这些情况下，您可以使用单一阶段提交(1PC)协议。当只有一个 XA 或非 XA 资源是全球交易的一部分时，使用单一阶段commnit 协议。

准备阶段通常会锁定资源，直到第二阶段处理为止。单阶段提交意味着跳过准备阶段，并且仅对资源处理提交。如果没有指定，则当全局交易仅包含一个参与者时，会自动使用单阶段提交优化。

最后资源提交优化(LRCO)

在非 XA 数据源参与 XA 事务的情况下，使用名为 Last Resource Commit Optimization(LRCO)的优化。虽然此协议允许大多数事务正常完成，但某些类型的错误可能会导致交易结果不一致。因此，仅将此方法用作最后的手段。

非 XA 资源在准备阶段结束时处理，并尝试进行提交。如果提交成功，则会写入事务日志，其余的资源将进入提交阶段。如果最后一个资源未能提交，则会回滚事务。

当在事务中使用一个本地 TX 数据源时，LRCO 会自动应用到它。

在以前的版本中，在 XA 事务中添加非 XA 资源是通过 LRCO 方法实现的。但是 LRCO 中存在一个故障窗口。使用 LRCO 方法将非 XA 资源添加到 XA 事务的步骤如下：

如果流程在步骤 2 和步骤 3 间崩溃，这可能会导致数据不一致，且您无法提交 XA 事务。数据不一致的原因是提交了 LRCO 非 XA 资源，但没有记录有关准备 XA 资源的信息。恢复管理器将在服务器启动后回滚资源。提交标记资源(CMR)消除了此限制，并允许将非 XA 资源可靠地加入 XA 事务。

SELECT xid,actionuid FROM _tableName_ WHERE transactionManagerID IN (String[])
DELETE FROM _tableName_ WHERE xid IN (byte[[]])
INSERT INTO _tableName_ (xid, transactionManagerID, actionuid) VALUES (byte[],String,byte[])

CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))

CREATE TABLE xids (xid RAW(144), transactionManagerID varchar(64), actionuid RAW(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)

CREATE TABLE xids (xid VARCHAR(255) for bit data not null, transactionManagerID
varchar(64), actionuid VARCHAR(255) for bit data not null)
CREATE UNIQUE INDEX index_xid ON xids (xid)

CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)

CREATE TABLE xids (xid bytea, transactionManagerID varchar(64), actionuid bytea)
CREATE UNIQUE INDEX index_xid ON xids (xid)

CREATE TABLE xids (xid BINARY(144), transactionManagerID varchar(64), actionuid BINARY(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)

CREATE TABLE xids (xid VARCHAR(255), transactionManagerID varchar(64), actionuid VARCHAR(255))
CREATE UNIQUE INDEX index_xid ON xids (xid)

<datasource enabled="true" jndi-name="java:jboss/datasources/ConnectableDS" pool-name="ConnectableDS" jta="true" use-java-context="true" connectable="true"/>

/subsystem=datasources/data-source=ConnectableDS:add(enabled="true", jndi-name="java:jboss/datasources/ConnectableDS", jta="true", use-java-context="true", connectable="true", connection-url="validConnectionURL", exception-sorter-class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter", driver-name="mssql")

<datasource jta="true" jndi-name="java:jboss/datasources/ConnectableDS" pool-name="ConnectableDS" enabled="true" use-java-context="true" connectable="true">
  <connection-url>validConnectionURL</connection-url>
  <driver>mssql</driver>
  <validation>
    <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"/>
  </validation>
</datasource>

/subsystem=datasources/data-source=ConnectableDS:write-attribute(name=connectable,value=true)

<subsystem xmlns="urn:jboss:domain:transactions:5.0">
    ...
    <commit-markable-resources>
        <commit-markable-resource jndi-name="java:jboss/datasources/ConnectableDS">
            <xid-location name="xids" batch-size="100" immediate-cleanup="false"/>
        </commit-markable-resource>
        ...
    </commit-markable-resources>
</subsystem>

/subsystem=transactions/commit-markable-resource=java\:jboss\/datasources\/ConnectableDS/:add(batch-size=100,immediate-cleanup=false,name=xids)

如果交易要回滚，它可以在本地记录此信息并通知所有参与方。该通知只是礼貌，对交易结果没有影响。联系了所有参与者后，可以删除有关交易的信息。

如果随后发生交易状态请求，则不会提供任何信息。在这种情况下，请求者假定事务已中止并回滚。这种假定的优化意味着，在决定提交交易之前，不需要使参与者的任何信息永久保留，因为在此之前的任何故障都将被视为交易的中止。

当要求参与者准备时，可以向协调者表明其在交易期间没有修改任何数据。不需要向这类参与者告知交易结果，因为参与者的承诺不会影响交易。提交协议的第二阶段中可以省略该只读参与者。

事务有三种可能的结果：

交易参与者提交时，将其新状态变为持久状态。新状态由参与者承担交易涉及的工作创建。最常见的示例是事务成员向数据库写入记录。

提交后，交易信息将从交易协调员中删除，新编写的状态现在是持久状态。

交易参与者回滚，恢复其状态以在交易开始前反映状态。回滚后，其状态与事务从未启动的情况相同。

启发性结果或非混合性的结果是交易参与者的决定不同于交易经理的决定的情况。启发性结果可能会导致系统完整性丢失，通常需要人工干预来解决它们。不要编写依赖于它们的代码。

启发式结果通常在 2 阶段提交(2PC)协议的第二阶段发生。在个别情况下，可能会在 1PC 中产生这个结果。它们通常由底层服务器基础硬件或通信子系统失败所致。

启发式结果可能源自各种子系统或资源的超时结果，即使事务管理器和完整崩溃恢复也是如此。在需要某种形式的分布式协议的任何系统中，系统的某些部分在全局结果上存在差异的情况。

启发式结果有四种：

Heuristic rollback

提交操作无法提交资源，但所有参与者都可以回滚，因此依然能实现原子性成果。

Heuristic commit

尝试回滚操作失败，因为所有参与者都已完成。例如，如果协调员能够成功准备交易，但随后决定回滚（例如，未能更新其日志），则会出现这种情况。此时，参与者可能决定提交。

Heuristic mix

某些参与者已提交，另一些已回滚。

启发式政府.

些更新的内容未知。对于已知的对象，它们或者全部已提交，或者全部已回滚。

有关 UserTransaction 类方法引发异常的详情，请查看 UserTransaction API Javadoc。

有关 Jakarta Transactions 的更多信息，请参阅关于 Jakarta Transactions。

当资源要求参与事务时，会启动一系列事件。事务管理器(TM)是一个驻留于应用程序服务器和管理事务的过程。交易参与者是指参与交易的对象。资源是数据源、雅加达消息传递连接工厂或其他 Jakarta Connectors 连接器连接。

当您需要在应用中使用事务时，以下步骤非常有用。

启发式事务结果不常见，通常具有特殊的原因。神秘一词意味着"手动"，这就是通常必须处理这些结果的方式。有关启发式事务结果的更多信息，请参阅关于 Heuristic Outcomes。

此流程演示了如何使用 Jakarta Transactions 处理交易的启发式结果。

本例演示了如何开始、提交和回滚 Jakarta Transactions 事务。您需要调整连接和数据源参数以适合您的环境，并在数据库中设置两个测试表。

public class JDBCExample {
    public static void main (String[] args) {
        Context ctx = new InitialContext();
        // Change these two lines to suit your environment.
        DataSource ds = (DataSource)ctx.lookup("jdbc/ExampleDS");
        Connection conn = ds.getConnection("testuser", "testpwd");
        Statement stmt = null; // Non-transactional statement
        Statement stmtx = null; // Transactional statement
        Properties dbProperties = new Properties();

        // Get a UserTransaction
        UserTransaction txn = new InitialContext().lookup("java:comp/UserTransaction");

        try {
            stmt = conn.createStatement();  // non-tx statement

            // Check the database connection.
            try {
                stmt.executeUpdate("DROP TABLE test_table");
                stmt.executeUpdate("DROP TABLE test_table2");
            }
            catch (Exception e) {
                throw new RuntimeException(e);
                // assume not in database.
            }

            try {
                stmt.executeUpdate("CREATE TABLE test_table (a INTEGER,b INTEGER)");
                stmt.executeUpdate("CREATE TABLE test_table2 (a INTEGER,b INTEGER)");
            }
            catch (Exception e) {
                throw new RuntimeException(e);
            }

            try {
                System.out.println("Starting top-level transaction.");

                txn.begin();

                stmtx = conn.createStatement(); // will be a tx-statement

                // First, we try to roll back changes

                System.out.println("\nAdding entries to table 1.");

                stmtx.executeUpdate("INSERT INTO test_table (a, b) VALUES (1,2)");

                ResultSet res1 = null;

                System.out.println("\nInspecting table 1.");

                res1 = stmtx.executeQuery("SELECT * FROM test_table");

                while (res1.next()) {
                    System.out.println("Column 1: "+res1.getInt(1));
                    System.out.println("Column 2: "+res1.getInt(2));
                }
                System.out.println("\nAdding entries to table 2.");

                stmtx.executeUpdate("INSERT INTO test_table2 (a, b) VALUES (3,4)");
                res1 = stmtx.executeQuery("SELECT * FROM test_table2");

                System.out.println("\nInspecting table 2.");

                while (res1.next()) {
                    System.out.println("Column 1: "+res1.getInt(1));
                    System.out.println("Column 2: "+res1.getInt(2));
                }

                System.out.print("\nNow attempting to rollback changes.");

                txn.rollback();

                // Next, we try to commit changes
                txn.begin();
                stmtx = conn.createStatement();
                System.out.println("\nAdding entries to table 1.");
                stmtx.executeUpdate("INSERT INTO test_table (a, b) VALUES (1,2)");
                ResultSet res2 = null;

                System.out.println("\nNow checking state of table 1.");

                res2 = stmtx.executeQuery("SELECT * FROM test_table");

                while (res2.next()) {
                    System.out.println("Column 1: "+res2.getInt(1));
                    System.out.println("Column 2: "+res2.getInt(2));
                }

                System.out.println("\nNow checking state of table 2.");

                stmtx = conn.createStatement();

                res2 = stmtx.executeQuery("SELECT * FROM test_table2");

                while (res2.next()) {
                    System.out.println("Column 1: "+res2.getInt(1));
                    System.out.println("Column 2: "+res2.getInt(2));
                }

                txn.commit();
            }
            catch (Exception ex) {
                throw new RuntimeException(ex);

            }
        }
        catch (Exception sysEx) {
            sysEx.printStackTrace();
            System.exit(0);
        }
    }
}

事务 Jakarta Transactions API 文档可作为 Javadoc 在以下位置找到：

如果您使用 Red Hat CodeReady Studio 来开发应用程序，API 文档会包括在 Help 菜单中。

事务范围的持久性上下文与活跃的 Jakarta Transactions 事务配合。事务提交时，持久性上下文刷新到数据源；实体对象会被分离，但可能仍被应用代码引用。预期要保存到数据源的所有实体更改必须在交易期间进行。当实体 管理器调用完成后，会在事务之外读取的实体 分离。

扩展的持久性上下文跨越多个事务，允许数据修改排队而无需活跃的 Jakarta Transactions 事务。容器管理的扩展持久性上下文只能注入有状态会话 Bean 中。

应用管理的实体管理器提供对底层持久性提供商 org.hibernate.jpa.HibernatePersistenceProvider 的直接访问。应用程序管理的实体管理器的范围从应用创建并持续到应用关闭的时间。您可以使用 @PersistenceUnit 注释将持久性单元注入 javax.persistence.EntityManagerFactory 接口，该界面返回应用管理的实体管理器。

当您的应用需要访问特定持久性单元中不通过 Jakarta Transactions 实例传播的持久性上下文时，可以使用应用管理 的实体管理器。在这种情况下，每个实体 管理器 实例都会创建一个新的隔离持久性上下文。您的应用程序将明确创建和销毁 实体管理器 实例及其关联的 PersistenceContext。当您无法直接注入实体管理器实例时，也可使用应用管理 的实体管理器，因为 实体管理器 实例不是线程安全。EntityManagerFactory 实例是 thread-safe。

@PersistenceUnit
EntityManagerFactory emf;
EntityManager em;
@Resource
UserTransaction utx;
...
em = emf.createEntityManager();
try {
    utx.begin();
    em.persist(SomeEntity);
    em.merge(AnotherEntity);
    em.remove(ThirdEntity);
    utx.commit();
}
catch (Exception e) {
    utx.rollback();
}

容器管理的实体管理器管理应用的底层持久性提供商。它们可以使用事务范围的持久性上下文或扩展持久性上下文。容器管理的实体管理器根据需要创建底层持久性提供商的实例。每次创建新的底层持久性提供商 org.hibernate.jpa.HibernatePersistenceProvider 实例时，都会创建一个新的持久性上下文。

默认情况下，JBoss EAP 不将 EntityManagerFactory 绑定到 JNDI。您可以通过设置 jboss.entity.manager .factory.jndi.name 属性，在应用的 persistence. xml 文件中显式配置此配置。此属性的值应当是您要将 EntityManagerFactory 绑定到的 JNDI 名称。

您还可以使用 jboss.entity.manager.jndi.name 属性将容器管理的事务范围实体管理器绑定到 JNDI。

<property name="jboss.entity.manager.jndi.name" value="java:/MyEntityManager"/>
<property name="jboss.entity.manager.factory.jndi.name" value="java:/MyEntityManagerFactory"/>

public User createUser(User user) {
    entityManager.persist(user);
    return user;
}

public void updateUser(User user) {
    entityManager.merge(user);
}

public void deleteUser(String user) {
    User user = findUser(username);
    if (user != null)
        entityManager.remove(user);
}

public User findUser(String username) {
    CriteriaBuilder builder = entityManager.getCriteriaBuilder();
    CriteriaQuery<User> criteria = builder.createQuery(User.class);
    Root<User> root = criteria.from(User.class);
    TypedQuery<User> query = entityManager
        .createQuery(criteria.select(root).where(
            builder.equal(root.<String> get("username"), username)));
    try {
        return query.getSingleResult();
    }
    catch (NoResultException e) {
        return null;
    }
}

第二级缓存是在应用会话外保留信息的本地数据存储。缓存由持久性提供商管理，通过将数据与应用分开来改进运行时。

JBoss EAP 支持用于以下目的的缓存：

<persistence ... version="2.2">
    <persistence-unit ...>
        ...
        <properties>
            <!-- Values below are not recommendations. Appropriate values should be determined based on system use/capacity. -->

            <!-- entity default overrides -->
            <property name="hibernate.cache.infinispan.entity.memory.size" value="5000"/>
            <property name="hibernate.cache.infinispan.entity.expiration.max_idle" value="300000"/> <!-- 5 minutes -->
            <property name="hibernate.cache.infinispan.entity.expiration.lifespan" value="1800000"/> <!-- 30 minutes -->
            <property name="hibernate.cache.infinispan.entity.expiration.wake_up_interval" value="300000"/>  <!-- 5 minutes -->

            <!-- local-query default overrides -->
            <property name="hibernate.cache.infinispan.query.memory.size" value="5000"/>
            <property name="hibernate.cache.infinispan.query.expiration.max_idle" value="300000"/> <!-- 5 minutes -->
            <property name="hibernate.cache.infinispan.query.expiration.lifespan" value="1800000"/> <!-- 30 minutes -->
            <property name="hibernate.cache.infinispan.query.expiration.wake_up_interval" value="300000"/> <!-- 5 minutes -->
        </properties>
    </persistence-unit>
</persistence>

验证约束应用到 Java 元素，如字段、属性或 bean。约束通常具有一组用于设置限值的属性。有预定义的限制，可以创建自定义限制。每个约束都以注释的形式表示。

Hibernate 验证器的内置验证限制如下：Hibernate 验证器约束。

Jakarta Bean Validation API 定义一组标准约束注释，如 @NotNull、@Size 等。但是，如果这些预定义的限制不够，您可以轻松创建针对特定验证要求量身定制的自定义限制。

创建 Jakarta Bean Validation 自定义约束要求您 创建一个约束注解 并实施约束验证器。以下缩写的代码示例取自 JBoss EAP 附带的 bean-validation-custom-constraint 快速入门：看到快速入门的完整工作示例。

package org.jboss.as.quickstarts.bean_validation_custom_constraint;

import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;
import org.jboss.as.quickstarts.bean_validation_custom_constraint.PersonAddress;

public class AddressValidator implements ConstraintValidator<Address, PersonAddress> {

    public void initialize(Address constraintAnnotation) {
    }

    /**
     * 1. A null address is handled by the @NotNull constraint on the @Address.
     * 2. The address should have all the data values specified.
     * 3. Pin code in the address should be of at least 6 characters.
     * 4. The country in the address should be of at least 4 characters.
     */
    public boolean isValid(PersonAddress value, ConstraintValidatorContext context) {
        if (value == null) {
            return true;
        }

        if (value.getCity() == null || value.getCountry() == null || value.getLocality() == null
            || value.getPinCode() == null || value.getState() == null || value.getStreetAddress() == null) {
            return false;
        }

        if (value.getCity().isEmpty()
            || value.getCountry().isEmpty() || value.getLocality().isEmpty()
            || value.getPinCode().isEmpty() || value.getState().isEmpty() || value.getStreetAddress().isEmpty()) {
            return false;
        }

        if (value.getPinCode().length() < 6) {
            return false;
        }

        if (value.getCountry().length() < 4) {
            return false;
        }

        return true;
    }
}