规则开发指南


Migration Toolkit for Applications 7.2

创建自定义规则以增强迁移覆盖。

Red Hat Customer Content Services

摘要

本指南介绍了如何为应用程序的 Migration Toolkit 创建自定义 XML 规则。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息

第 1 章 简介

1.1. 关于规则开发指南

本指南适用于希望为应用程序(MTA)工具创建自定义基于 YAML 的规则的软件工程师。

详情请参阅 Migration Toolkit for Applications 简介 for a overview 和 CLI 指南

1.1.1. 本指南使用 <MTA_HOME>

本指南使用 <MTA_HOME> 可替换变量来指示您的 MTA 安装的路径。

mta-7.2.0-cli<OS>.zip* 提取一个名为 mta-cli 的二进制文件。

在本指南中遇到 <MTA_HOME> 时,将其替换为 MTA 安装的实际路径。

1.2. MTA 规则

Migration Toolkit for Applications (MTA)包含基于规则的迁移工具(分析器),可用于分析您计划迁移的应用程序用户界面(API)、技术和架构。MTA 分析器规则使用以下规则模式:

when(condition)
 message(message)
 tag(tags)

您可以在内部使用 MTA 规则来执行以下任务:

  • 从存档中提取文件.
  • 解译文件。
  • 扫描和分类文件类型。
  • 分析 XML 和其他文件内容。
  • 分析应用程序代码。
  • 构建报告。

MTA 根据规则执行结果构建数据模型,并将组件数据和关系存储在图形数据库中。然后,可以根据迁移规则的要求和报告目的来查询和更新此数据库。

注意

您可以创建自己的自定义分析器规则。您可以使用自定义规则来识别提供标准迁移规则未涵盖的自定义库或其他组件。

第 2 章 创建 YAML 规则

每个分析器规则是一组用于分析源代码并检测迁移问题的指令。

分析器解析用户提供的规则,将它们应用到应用程序的源代码,并为匹配规则生成问题。一个或多个规则的集合形成规则集。创建规则集提供了一种组织实现常见目标的多个规则的方法。分析器 CLI 将 rulesets 用作输入参数。

2.1. YAML 规则结构和语法

MTA 规则使用 YAML 编写。每个规则由元数据、条件和操作组成,它指示分析器在给定条件匹配时执行指定的操作。

MTA 中的 YAML 规则文件包含一个或多个 YAML 规则。

2.1.1. 规则元数据

规则元数据包含有关规则的一般信息。元数据的结构如下:

ruleId: "unique_id" 1
labels: 2
  # key=value pair
  - "label1=val1"
  # valid label with value omitted
  - "label2"
  # valid label with empty value
  - "label3="
  # subdomain prefixed key
  - "konveyor.io/label1=val1"
effort: 1 3
category: mandatory 4
1
该 ID 在规则所属的规则集内必须是唯一的。
2
有关标签格式的描述,请参见以下信息。
3
effort 是一个整数值,表示解决这个问题所需的工作量程度。
4
category 描述了迁移问题的严重性。该值可以是 强制的可选潜在的。有关这些类别的描述,请参阅 规则类别
2.1.1.1. 规则标签

标签是为规则或规则集以及依赖项指定的 key=val 对。对于依赖项,供应商会在检索依赖项时添加标签。规则集上的标签由属于它的所有规则自动继承。

标签格式

标签在 labels 字段中指定为 key=val 格式的字符串列表,如下所示:

labels:
- "key1=val1"
- "key2=val2"

标签的键可以是子域前缀:

labels:
- "konveyor.io/key1=val1"

标签的值可以为空:

labels:
- "konveyor.io/key="

标签的值可以省略。在这种情况下,它将被视为空值:

labels:
- "konveyor.io/key"

保留标签

分析器定义了一些具有特殊含义的标签,如下所示:

  • konveyor.io/source :标识应用规则或规则集的源技术
  • konveyor.io/target: 标识应用规则或规则集的目标技术

标签选择器

分析器 CLI 将 --label-selector 字段用作选项。这是一个字符串表达式,支持逻辑 AND、OR 和 NOT 操作。您可以使用它来根据其标签过滤或过滤出规则。

示例:

  • 要过滤所有带有键 konveyor.io/source 且值为 eap6 的规则:

    --label-selector="konveyor.io/source=eap6"

  • 要过滤所有带有键 konveyor.io/source 和任何值标签的规则:

    --label-selector="konveyor.io/source"

  • 使用 & amp;& operator 对多个规则都匹配逻辑 AND 操作:

    --label-selector="key1=val1 && key2"

  • 使用 || 运算符对多个规则执行逻辑 OR 操作:

    --label-selector="key1=val1 || key2"

  • 要执行 NOT 操作来过滤使用 ! operator 设置 key1=val1 标签的规则:

    --label-selector="!key1=val1"

  • 使用 AND 对子表达式进行分组和控制优先级:

    --label-selector="(key1=val1 || key2=val2) && !val3"

依赖项标签

分析器引擎为依赖项添加标签。这些标签提供有关依赖项的额外信息,如其编程语言以及依赖项是否为开源还是内部。

目前,分析器会将以下标签添加到依赖项中:

labels:
- konveyor.io/dep-source=internal
- konveyor.io/language=java

依赖项标签选择器

分析器 CLI 接受 --dep-label-selector 选项,该选项允许根据标签从依赖项生成的 filtering-in 或 filtering-out 事件。

例如,分析器将 konveyor.io/dep-source 标签添加到依赖项中,其值表示依赖项是否为已知的开源依赖项。

要排除所有此类开源依赖项的事件,您可以使用 -dep-label-selector,如下所示:

konveyor-analyzer …​ --dep-label-selector !konveyor.io/dep-source=open-source

分析器中的 Java 供应商也可以向软件包列表添加一个 exclude 标签。要排除所有这样的软件包,您可以使用 --dep-label-selector! operator,如下所示:

konveyor-analyzer …​ --dep-label-selector !konveyor.io/exclude

2.1.1.2. 规则类别
  • 必需

    • 您必须解决成功迁移的问题,否则生成的应用程序不会成功构建或运行。此类问题的一个示例是目标平台上不支持的专有 API。
  • optional

    • 如果您没有解决这个问题,应用程序应该可以正常工作,但结果可能不是最佳。如果您没有在迁移时进行更改,则需要在迁移完成后尽快按计划设置。例如,EJB 2.x 代码没有升级到 EJB 3。
  • potential

    • 您需要在迁移过程中检查问题,但没有足够的信息来确定解决问题是否强制迁移成功。例如,当目标平台上没有直接兼容类型时,迁移第三方专有类型。
2.1.1.3. 规则操作

规则可以包含两类操作: messagetag。每个规则包括其中一个或两个。

消息操作

当规则匹配时,message 操作会创建一条消息的问题。供应商导出的自定义数据也可以在消息中使用。

Message: "helpful message about the issue"

Example:

- ruleID: test-rule
  when:
    <CONDITION>
  message: Test rule matched. Please resolve this migration issue.

(可选)消息可以包含超链接到外部 URL,它们提供有关问题或快速修复相关信息。

links:
  - url: "konveyor.io"
    title: "Short title for the link"

消息也可以是模板,其中包含有关通过规则上的自定义变量插入的匹配项的信息。

标签操作

tag 操作指示分析器在找到匹配项时为应用程序生成一个或多个标签。tag 字段中的每一字符串可以是以逗号分隔的标签列表。另外,您可以为标签分配类别。

tag:
  - "tag1,tag2,tag3"
  - "Category=tag4,tag5"

Example

- ruleID: test-rule
  when:
    <CONDITION>
  tag:
  - Language=Golang
  - Env=production
  - Source Code

标签可以是字符串或 key=val 对,其中密钥被视为 MTA 中的标签类别。具有标签操作的任何规则都被称为本文档中的"标记规则"。

请注意,不会为仅包含标签操作的规则创建问题。

2.1.1.4. 规则条件

每个规则都有 when block,它指定了对 MTA 执行某个操作需要满足的条件。

when 块包含一个条件,但该条件可以在它下嵌套多个条件。

when:
  <condition>
    <nested-condition>

MTA 支持三种类型的条件: provider

2.1.1.4.1. 供应商条件

应用程序分析器检测到用于构建应用程序的编程语言、框架和工具,并相应地使用语言服务器协议(LSP)为每个支持的供应商生成默认规则集。每个支持的供应商都默认定义了一个规则集,并在单独的容器中运行。

MTA 支持多语言源代码分析。使用 供应商 条件启用源代码中的特定语言。此条件定义了特定语言提供程序的搜索查询。供应商 条件还指定用于分析代码的提供程序的"功能"的"功能"。

供应商 条件格式为 < provider_name>.<capability>

when:
  <provider_name>.<capability>
    <input_fields>

分析器目前支持以下供应商 条件

  • builtin
  • java
  • go
  • dotnet
重要

在 CLI 上分析多个应用程序时,支持提供单个报告只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

供应商规则条件供应商名称

完全支持并包含在产品中的供应商

Java

在产品中已定义了规则的供应商

.NET

需要自定义规则集进行分析的供应商

  • Go
  • Python
  • Node.js
2.1.1.4.1.1. 内置 供应商

内置 是一个内部供应商,它可以分析引擎生成的各种文件和内部元数据。

这个供应商有以下功能:

  • file
  • FileContent
  • xml
  • json
  • hasTags

file

文件 功能可让供应商搜索与给定模式匹配的源代码中的文件。

when:
  builtin.file:
    pattern: "<regex_to_match_filenames>"

FileContent

filecontent 功能使供应商能够搜索与给定模式匹配的内容。

when:
  builtin.filecontent:
    filePattern: "<regex_to_match_filenames_to_scope_search>"
    pattern: "<regex_to_match_content_in_the_matching_files>"

xml

xml 功能可让供应商查询提供的 XML 文件列表中的 XPath 表达式。此功能采用 2 个输入参数 xpath文件路径

when:
  builtin.xml:
    xpath: "<xpath_expressions>" 1
    filepaths: 2
      - "/src/file1.xml"
      - "/src/file2.xml"
1
XPath 必须是有效的 XPath 表达式。
2
filepaths 是要应用 XPath 查询的文件列表。

json

json 功能可让供应商在提供的 JSON 文件列表中查询 XPath 表达式。目前,json 仅采用 XPath 作为输入,并对代码库中的所有 JSON 文件执行搜索。

when:
  builtin.json:
    xpath: "<xpath_expressions>" 1
1
XPath 必须是有效的 XPath 表达式。

hasTags

hasTags 功能使供应商能够查询应用程序标签。它查询内部数据结构,以检查应用是否有给定的标签。

when:
  # when more than one tag is given, a logical AND is implied
  hasTags: 1
    - "tag1"
    - "tag2"
1
当有多个标签时,意味着一个逻辑 AND。
2.1.1.4.1.2. Java 供应商

java 供应商分析 Java 源代码。

这个供应商有以下功能:

  • 引用
  • 依赖项

引用

引用 的功能可让供应商在源代码中查找引用。此功能采用三种输入参数: 模式位置注释

when:
  java.referenced:
    pattern: "<pattern>" 1
    location: "<location>" 2
    annotated: "<annotated>" 3
1
要匹配的正则表达式模式,如 org.kubernetesoriented
2
指定需要匹配模式的确切位置,例如 IMPORT
3
使用查询检查特定注解及其元素,如 Java 代码中的名称和值。例如,以下查询与方法中的 Bean (url = "http://www.example.com”)注解匹配。
 annotated:
      pattern: org.framework.Bean
      elements:
      - name: url
        value: "http://www.example.com"

支持的位置如下:

  • CONSTRUCTOR_CALL
  • TYPE
  • 继承
  • METHOD_CALL
  • 注解
  • IMPLEMENTS_TYPE
  • ENUM_CONSTANT
  • RETURN_TYPE
  • IMPORT
  • VARIABLE_DECLARATION
  • 字段
  • 方法

依赖项

依赖项 功能可让供应商查找给定应用程序的依赖项。MTA 生成应用程序的依赖项列表,您可以使用此功能查询列表,并检查是否在依赖项版本范围内的应用程序中存在特定的依赖项。

when:
  java.dependency:
    name: "<dependency_name>" 1
    upperbound: "<version_string>" 2
    lowerbound: "<version_string>" 3
1
要搜索的依赖项的名称。
2
对依赖项版本进行上限。
3
对依赖项版本的绑定较低。
2.1.1.4.1.3. Go 供应商

Go 供应商分析 Go 源代码。此提供程序的功能 被引用依赖项 为。

引用

引用 的功能可让供应商在源代码中查找引用。

when:
  go.referenced: "<regex_to_find_reference>"

依赖项

依赖项 功能可让供应商查找应用程序的依赖项。

when:
  go.dependency:
    name: "<dependency_name>" 1
    upperbound: "<version_string>" 2
    lowerbound: "<version_string>" 3
1
要搜索的依赖项的名称。
2
对依赖项版本进行上限。
3
对依赖项版本的绑定较低。
2.1.1.4.1.4. dotnet 供应商

dotnet 是一个外部供应商,用于分析 .NET 和 C# 源代码。目前,供应商支持 引用 的功能。

引用

引用 的功能可让供应商在源代码中查找引用。

when:
  dotnet.referenced:
    pattern: "<pattern>" 1
    namespace: "<namespace>" 2
1
Pattern: 匹配所需参考的正则表达式模式。例如,HttpNotFound。
2
Namespace: 指定要在其中搜索的命名空间。例如: System.Web.Mvc。
2.1.1.4.2. 自定义变量

供应商条件可以关联有自定义变量。您可以使用自定义变量从源代码中的匹配行捕获相关信息。这些变量的值与源代码中匹配的数据进行干预。这些值可用于在规则的操作中生成详细的模板消息(请参阅 消息操作)。它们可以添加到 customVariables 字段中的规则中:

- ruleID: lang-ref-004
   customVariables:
   - pattern: '([A-z]+)\.get\(\)' 1
      name: VariableName 2
    message: "Found generic call - {{ VariableName }}" 3
  when:
      java.referenced:
          location: METHOD_CALL
          pattern: com.example.apps.GenericClass.get
1
Pattern : 找到匹配项时在源代码行上匹配的正则表达式模式。
2
Name :可以在模板中使用的变量名称。
3
Message: 使用自定义变量消息的模板。
2.1.1.5. 逻辑条件

分析器提供两个基本逻辑条件, ,供您聚合其他条件的结果并创建更复杂的查询。

2.1.1.5.1.  条件

and 条件对条件数组的结果执行逻辑 AND 操作。当 所有子 条件都匹配时,和 条件都匹配。

when:
  and:
    - <condition1>
    - <condition2>

Example

when:
  and:
    - java.dependency:
        name: junit.junit
        upperbound: 4.12.2
        lowerbound: 4.4.0
    - java.referenced:
        location: IMPORT
        pattern: junit.junit

条件也可以嵌套在其他条件内。

Example

when:
  and:
  - and:
    - go.referenced: "*CustomResourceDefinition*"
    - java.referenced:
        pattern: "*CustomResourceDefinition*"
  - go.referenced: "*CustomResourceDefinition*"
2.1.1.5.2.  条件

or 条件对条件数组的结果执行逻辑 OR 操作。当任何子条件都匹配时, 条件会匹配。

when:
  or:
    - <condition1>
    - <condition2>

Example

when:
  or:
  - java.dependency:
      name: junit.junit
      upperbound: 4.12.2
      lowerbound: 4.4.0
  - java.referenced:
      location: IMPORT
      pattern: junit.junit

2.1.2. Rulesets(规则集)

组规则形成规则集。MTA 不需要每个规则文件属于规则集,但您可以使用规则集来对实现常见目标的多个规则进行分组,并将规则传递给规则引擎。

您可以通过将一个或多个 YAML 规则放在目录中,并在目录 root 中创建 ruleset.yaml 文件来创建规则集。当您使用- rules 选项将该目录作为输入传递给 MTA CLI 时,此目录中的所有规则都将被视为 ruleset.yaml 文件定义的规则集的一部分。

ruleset.yaml 文件存储规则集的元数据。

name: "Name of the ruleset" 1
description: "Description of the ruleset"
labels: 2
  - key=val
1
该名称在提供的规则集内必须是唯一的。
2
ruleset 标签由属于规则集的所有规则继承。

要执行任何应用程序分析,请运行以下命令:将 <application_to_analyze> 替换为您的应用程序,<output_dir> 替换为您选择的目录,<custom_rule_dir> 替换为自定义规则集文件。

$ mta-cli analyze --input=<application_to_analyze> --output=<output_dir> --rules=<custom_rule_dir> --enable-default-rulesets=false

在启动时,mta-cli 工具决定了应用程序的类型以及分析所需的相应供应商。然后,它会在具有所需依赖项和工具的容器中启动提供程序。最后,提供商使用分析器来执行一系列规则集来分析源代码。

2.2. 创建基本 YAML 规则

本节论述了如何创建基本 MTA YAML 规则。假设您已安装了 MTA。有关安装说明,请参阅 MTA CLI 指南

2.2.1. 创建基本 YAML 规则模板

基于 MTA YAML 的规则有以下基本结构:

when(condition)
 message(message)
 tag(tags)

流程

  1. /home/<USER& gt;/ 目录中,创建一个文件,其中包含 YAML 规则的基本语法,如下所示:

    - category: mandatory
      description: |
       <DESCRIPTION TITLE>
       <DESCRIPTION TEXT>
      effort: <EFFORT>
      labels:
      - konveyor.io/source=<SOURCE_TECH>
      - konveyor.io/target=<TARGET_TECH>
      links:
     - url: <HYPERLINK>
       title: <HYPERLINK_TITLE>
      message: <MESSAGE>
      tag:
      - <TAG1>
      - <TAG2>
      ruleID: <RULE_ID>
      when:
       <CONDITIONS>

2.2.2. 创建基本 YAML 规则集模板

如果要对多个类似的规则进行分组,可以通过将其文件放在一个目录中并在目录 root 中创建 ruleset.yaml 文件来为它们创建一个规则集。当您使用- rules 选项将此目录作为输入传递给 MTA CLI 时,MTA 会将目录中的所有文件视为属于 ruleset.yaml 文件中定义的规则集。

流程

  1. 如果要使用- rules 选项传递整个目录,请为 ruleset.yaml 文件创建一个模板:

    name: <RULESET_NAME> 1
    description: <RULESET_DESCRIPTION>
    labels: 2
      - key=val
    1
    该名称在提供的规则集内必须是唯一的。
    2
    ruleset 标签由属于规则集的所有规则继承。

2.2.3. 创建 YAML 规则

每个规则文件包含一个或多个 YAML 规则。每个规则都包含元数据、条件和操作。

流程

  1. 创建 when 条件。

    YAML 规则的 when 条件可以是 provider

    1. 创建 供应商 条件

      provider 条件用于定义对特定语言提供程序的搜索查询,并调用提供程序的特定功能。

      条件的一般格式为 < provider_name>.<capability>。该条件还具有 inner 字段,用于指定搜索的详细信息。创建 供应商 条件及其内部字段的方式取决于您使用的供应商以及您调用的功能。

      下表列出了可用的提供程序及其功能。选择一个供应商及其功能,以满足您要创建的规则的目的。条件的一部分还没有包含任何条件的字段。

      供应商功能描述

      java

      引用

      找到模式引用,包括注解,带有可选代码位置,用于详细搜索

      依赖项

      检查应用程序是否有给定依赖项

      builtin

      xml

      使用 XPath 查询搜索 XML 文件

      json

      使用 JSONPath 查询搜索 JSON 文件

      FileContent

      使用 RegEx 模式搜索常规文件中的内容

      file

      查找名称与给定模式匹配的文件

      hasTags

      检查是否通过标记规则为应用程序创建标签

      go

      引用

      查找模式引用

      依赖项

      检查应用程序是否有给定依赖项

      以下示例显示了使用 引用 能力的 java 供应商条件。

      Example

      when:
        java.referenced:
  2. 供应商 条件添加合适的字段。

    下表列出了所有可用的供应商、其功能及其字段。选择属于您选择的供应商和功能的字段。请注意,一些字段是必须的。

    供应商功能字段必需?描述

    java

    引用

    pattern

    RegEx pattern

    位置

    源代码位置;请参阅下面所有支持的搜索位置列表

    annotated

    注解及其元素(名称和值)

    依赖项

    名称

    依赖项的名称

    nameregex

    与名称匹配的正则表达式模式

    upperBound

    匹配小于或等于的版本号

    lowerBound

    匹配大于或等于的版本号

    builtin

    xml

    XPath

    XPath 查询

    命名空间

    映射到范围向下查询到命名空间

    filepaths

    用于范围搜索的可选文件列表

    json

    XPath

    XPath 查询

    filepaths

    用于范围搜索的可选文件列表

    FileContent

    pattern

    在内容中匹配的正则表达式模式

    filePattern

    仅在与此模式匹配的文件中搜索

    file

    pattern

    查找与此模式匹配的名称的文件

    hasTags

    这是字符串标签的内联列表。有关标签格式的详情,请参阅 Rule Actions 中的 Tag Actions

    go

    引用

    pattern

    RegEx pattern

    依赖项

    名称

    依赖项的名称

    nameregex

    与名称匹配的正则表达式模式

    upperBound

    匹配小于或等于的版本号

    lowerBound

    匹配大于或等于的版本号

    以下搜索位置可用于范围 java 搜索:

    • CONSTRUCTOR_CALL
    • TYPE
    • 继承
    • METHOD_CALL
    • 注解
    • IMPLEMENTS_TYPE
    • ENUM_CONSTANT
    • RETURN_TYPE
    • IMPORT
    • VARIABLE_DECLARATION

      以下示例显示搜索软件包引用的规则的 when 条件。

      Example

      when:
        java.referenced:
          location: PACKAGE
          pattern: org.jboss.*
  3. 创建 ANDOR 条件

    • 所有子 条件都匹配时,和 条件都匹配。创建 条件,如下所示:

      when:
        and:
        - java.dependency:
            name: junit.junit
            upperbound: 4.12.2
            lowerbound: 4.4.0
        - java.referenced:
            location: IMPORT
            pattern: junit.junit
    • 当任何子条件都匹配时, 条件会匹配。创建 条件,如下所示:

      when:
        or:
        - java.dependency:
            name: junit.junit
            upperbound: 4.12.2
            lowerbound: 4.4.0
        - java.referenced:
            location: IMPORT
            pattern: junit.junit

2.2.4. 使用自定义 YAML 规则运行分析

要运行分析,请在 CLI 中使用-- rules 选项。

流程

  • 要在一条规则文件 /home/<USER>/rule.yaml 中使用规则,请运行以下命令:

    mta-cli analyze --input /home/<USER>/data/ --output /home/<USER>/output/ --rules /home/<USER>/rule.yaml

    其中:

    • /home/<USER>/data/ - 源代码或二进制的目录
    • /home/<USER>/output/ - 报告的目录(HTML 和 YAML)
  • 要使用多个规则文件,您需要将它们放在目录中并添加 ruleset.yaml 文件。然后,目录被视为 规则集,您可以将其作为输入传递给 规则 选项。

请注意,如果您要在 CLI 中使用-- target 或-- source 选项,则引擎将仅选择与该目标标签匹配的规则。因此,请确保您在规则上添加了目标或源标签。如需了解更多详细信息,请参阅 保留标签

2.3. 创建第一个 YAML 规则

本节介绍了创建和测试第一个基于 MTA YAML 的规则的过程。这假设您已安装了 MTA。有关安装说明 请参阅 CLI 指南中的 安装和运行 CLI。

在本例中,您将创建一个规则来发现应用程序定义了包含 < class-loading> 元素的 jboss- web.xml 文件,并提供描述如何迁移代码的文档的链接。

2.3.1. 为规则创建 YAML 文件

  • 为您的第一个规则创建一个 YAML 文件。
$ mkdir /home/<USER>/rule.yaml

2.3.2. 创建数据来测试规则

  1. 在目录中创建 jboss-web.xmlpom.xml 文件:

    mkdir /home/<USER>/data/
    touch /home/<USER>/data/jboss-web.xml
    touch /home/<USER>/data/pom.xml
  2. 在您创建的 jboss-web.xml 文件中,粘贴以下内容:

    <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd">
    <jboss-web>
        <class-loading java2ClassLoadingCompliance="false">
            <loader-repository>
                seam.jboss.org:loader=@projectName@
                <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
            </loader-repository>
        </class-loading>
    </jboss-web>
  3. 在您创建的 pom.xml 文件中,粘贴以下内容:

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    
      <groupId>test</groupId>
      <artifactId>test</artifactId>
      <version>1.1.0-SNAPSHOT</version>
    
      <properties>
    	<maven.compiler.source>1.7</maven.compiler.source>
    	<maven.compiler.target>1.7</maven.compiler.target>
      </properties>
    
      <dependencies>
      </dependencies>
    </project>

2.3.3. 创建规则

基于 MTA YAML 的规则使用以下规则模式:

when(condition)
  perform(action)

流程

  • 在您创建的 rule.yaml 文件中,粘贴以下内容:

    - ruleID: <UNIQUE_RULE_ID> 1
      description: <DESCRIPTION> 2
      when:
        <CONDITION(S)> 3
      message: <MESSAGE> 4
      labels: <LABELS> 5
      effort: <EFFORT> 6
      links:
      - <LINKS> 7
    1
    规则的唯一 ID。例如,jboss5-web-class-loading
    2
    规则的文本描述。
    3
    完成 when 块指定一个或多个条件:
    1. 使用 内置 提供程序的 XML 功能,因为此规则检查 XML 文件中的匹配项。
    2. 要在作为 jboss -web 的子类加载 元素上匹配,请使用 XPath 表达式 jboss-web/web-loading 作为 XML 查询。在这种情况下,您只需要一个条件:

      when:
        builtin.xml:
          xpath: jboss-web/class-loading
    4
    解释迁移问题的有用消息。当规则匹配时,报告中会生成该消息。例如:
    message: The class-loading element is no longer valid in the jboss-web.xml file.
    5
    规则的字符串标签列表。
    6
    解决这个问题的预期故事数。
    7
    一个或多个超链接指向您找到的迁移问题的文档。
    links:
    - url: https://access.redhat.com/documentation/zh-CN/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#Create_or_Modify_Files_That_Control_Class_Loading_in_JBoss_Enterprise_Application_Platform_6
      title: Create or Modify Files That Control Class Loading in JBoss EAP 6

    该规则现已完成,并类似如下:

    - ruleID: jboss5-web-class-loading
      description: Find class loading element in JBoss XML file.
      when:
        builtin.xml:
          xpath: jboss-web/class-loading
      message: The class-loading element is no longer valid in the jboss-web.xml file.
      effort: 3
      links:
      - url: https://access.redhat.com/documentation/zh-CN/JBoss_Enterprise_Application_Platform/6.4/html-single/Migration_Guide/index.html#Create_or_Modify_Files_That_Control_Class_Loading_in_JBoss_Enterprise_Application_Platform_6
        title: Create or Modify Files That Control Class Loading in JBoss EAP 6

2.3.4. 安装规则

流程

  • 将 CLI 指向您创建的规则文件:

    –rules /home/<USER>/rules.yaml

2.3.5. 测试规则

流程

要测试规则,请将输入指向您创建的测试数据,并使用 MTA CLI 中的 rules 选项传递规则:

mta-cli analyze --input /home/<USER>/data/ --output /home/<USER>/output/ --rules /home/<USER>/rules.yaml

2.3.6. 查看报告

查看报告以确保它提供了预期的结果。

流程

  1. 分析完成后,命令会输出 HTML 报告的路径:

    INFO[0066] Static report created. Access it at this URL:  URL="file:/home/<USER>/output/static-report/index.html"

    在 Web 浏览器中打开 /home/<USER_NAME>/output/static-report/index.html

  2. 进入到左侧菜单中的 issues 选项卡。
  3. 验证规则是否已执行:

    1. issues 表中,在搜索栏中输入 JBoss XML
    2. 验证表中是否存在 title Find class loading 元素 的问题。
  4. 单击 jboss-web.xml 链接,以打开受影响的文件。

附录 A. 参考材料

A.1. 关于规则故事点

A.1.1. 什么是故事点?

故事点是敏捷软件开发中常用的抽象指标,用于估算实施功能或更改所需的工作量水平

应用的 Migration Toolkit for Applications 使用故事点来代表迁移特定应用程序构造所需的工作程度,以及整个应用程序。它不一定转换为“人-小时”,但该值在不同的任务间应保持一致。

A.1.2. 故事点如何在规则中估计

估算一个规则的故事点的工作量水平可能很棘手。以下是估算规则所需工作量时,使用的一般准则 MTA。

努力级别故事点描述

信息

0

迁移过程中具有非常低或没有优先级的信息。

微小

1

迁移是一个微小的变化或一个简单的库交换,没有或有最小的 API 更改。

复杂

3

迁移任务所需的更改比较复杂,但有一个已包括在文档中的解决方案。

重新设计

5

迁移任务需要重新设计或完整的库更改,并有显著的 API 更改。

架构重组

7

迁移会需要组件或子系统的完全的架构重组。

Unknown

13

迁移解决方案并非已知的,可能需要进行彻底的重写。

A.1.3. 任务类别

除了工作程度外,您还可以对迁移任务进行分类,以指明任务的严重性。下列类别用于对问题进行分组,以帮助确定迁移的工作量。

必需
必须成功完成该任务才能成功迁移。如果没有进行任何更改,则生成的应用不会成功构建或运行。例如,替换在目标平台中不支持的专有 API。
选填
如果没有完成迁移任务,应用程序应该可以正常工作,但结果可能不是最佳。如果迁移时没有进行任何更改,建议在迁移完成后尽快按计划设置。
Potential
应在迁移过程中检查该任务,但没有足够的详细信息来确定任务是否成功完成。当没有直接兼容类型时,这将迁移第三方专有类型。
信息
该任务会包括告知您存在某些文件。可能需要将它们检查或修改为现代化工作的一部分,但通常不需要进行更改。

A.2. 其他资源

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.