【问题标题】:Pact JVM update backwards compatibilityPact JVM 更新向后兼容性
【发布时间】:2018-03-09 12:17:47
【问题描述】:

我正在尝试将数十个服务从 au.com.dius:pact-jvm-consumer-junit_2.11:3.2.13 更新为 au.com.dius:pact-jvm-consumer-junit_2.12:3.5.12,但似乎新的消费者版本正在生成旧提供者版本 (au.com.dius:pact-jvm-provider-junit_2.11:3.2.13) 无法处理的协议。

旧协议有一个哈希图,在根目录中添加了匹配规则,如下所示

{
    "consumer": {
        "name": "consumer-amqp"
    },
    "provider": {
        "name": "prodvider-amqp"
    },
    "messages": [
        {
            "description": "amqp contract",
            "contents": {
                "body": {
                    "guidProperty": "795ecfd5-a3a5-430f-a0cd-1569df61bff6"
                }
            },
            "matchingRules": {
                "$.body.body.guidProperty": {
                    "regex": "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
                }
            }
        }
    ],
    "metadata": {
        "pact-specification": {
            "version": "3.0.0"
        },
        "pact-jvm": {
            "version": "3.2.13"
        }
    }
}

新的消费者在匹配器周围添加和包装body。以下是使用新消费者版本生成的相同协议的示例

{
  "consumer": {
    "name": "consumer-amqp"
  },
  "provider": {
    "name": "prodiver-amqp"
  },
  "messages": [
    {
      "description": "contract",
      "contents": {
        "body": {
          "guidProperty": "e2490de5-5bd3-43d5-b7c4-526e33f71304"
        }
      },
      "matchingRules": {
        "body": {
          "$.guidProperty": {
            "matchers": [
              {
                "match": "regex",
                "regex": "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
              }
            ],
            "combine": "AND"
          }
        }
      }
    }
  ],
  "metadata": {
    "pact-specification": {
      "version": "3.0.0"
    },
    "pact-jvm": {
      "version": "3.5.12"
    }
  }
}

由于该更改,提供程序无法解析匹配规则并出现以下错误:

body
^
10:21:24.526 [main] DEBUG au.com.dius.pact.matchers.JsonBodyMatcher - compareValues: No matcher defined for path List($, body, body, guidProperty), using equality
10:21:24.527 [main] WARN au.com.dius.pact.matchers.Matchers$ - Path expression body is invalid, ignoring: [1.1] failure: `$' expected but `b' found

java.lang.AssertionError: 

comparison

{$.body.body.guidProperty=Expected 'e2490de5-5bd3-43d5-b7c4-526e33f71304' but received 'aff876f5-5014-937c-6855-c099f9857437'

看v3的spec新消息好像是有效的,老的provider library(v3.2.13)不支持吗?查看代码发现这个commit在我看来,更改是从哪里引入的。

根据我的测试,新的提供程序库 (3.5.12) 可以处理新旧格式,但如果类路径中同时存在新的提供程序库和旧的消费者库,则 http 合约测试会因运行时错误而失败。

问题

1) 有没有办法强制新消费者以旧方式创建契约,并且该表单规范是否符合要求?

2) 有没有办法将提供程序更新到新版本,并且路径中仍然有旧的消费者库并且不会失败?

【问题讨论】:

  • 您是否尝试过指定协议规范版本 2 而不是 3?我没有看到 3 会给你超过 2 的任何功能,因为 3 仍在开发中。 2 是我们目前考虑的 LTS。请先尝试看看它是否有效,如果没有,请在 repo 上创建一个引用导致问题的提交的问题,因为这应该被视为一个错误。干杯。
  • 我尝试了第 2 版,这适用于某些协议。不幸的是,我也有仅在版本 3 中支持的消息协定。

标签: pact pact-jvm


【解决方案1】:

正如 J_A_X 指出的那样,看起来您引用的提交修复了一个错误,即本应是版本 3 的协议不完全符合版本 3(他们使用旧的匹配器格式)

1) 有没有办法强制新消费者以旧方式创建契约,并且该表单规范是否符合要求?

是的,是的。您应该能够通过将系统属性 pact.provider.version 设置为 2 来解决此问题 - 然后新旧版本都将能够读取生成的协议。

2) 有没有办法将提供程序更新到新版本,并且路径中仍然有旧的消费者库并且不会失败?

可以,只要您要求旧的消费者版本生成版本2 契约(但理想情况下,为什么不将两者都更新到相同的版本?)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-08-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-04-17
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多