Closed IschenkoArtem closed 9 years ago
Interesting. The path $.body.2.str
is not Javascript, it's JSON Path, and I haven't seen numeric keys specified in any different way. I suspect the code that looks up the path actually has the problem.
Code that looks up the path uses JSONPath lib from gatling, which clearly doesn't want for field to start with number: https://github.com/gatling/jsonpath/blob/master/src/main/scala/io/gatling/jsonpath/Parser.scala#L52
So is gatling lib incorrect?
You are correct, the field regular expression in gatling is expecting a field to start with a lower case character, underscore or dollar.
I'll update the consumer DSLs to write ['2']
when it is a numeric field.
Hm, not super keen on the fact that a quirk in a JVM library is going to force every other Pact implementation in different languages to support this quirk in behaviour that I'm not even convinced is valid JSONPath (it may well be, but I haven't seen any evidence for it).
If we're going to do this, we need a pact-spec for it.
['2']
is valid jsonpath. I refer you to http://goessner.net/articles/JsonPath/ on the part about the bracket–notation: $['store']['book'][0]['title']
Yes, it's a valid jsonpath for an array lookup. But an object lookup?
Ah, I see what you mean. if $['store']
is valid then $['2']
is valid. Ok, all good then.
I've released version 2.2.4 with the fix to pact-jvm-consumer-junit for this.
Very much appreciated. Will check that later.
My example works now. Result is: $.body['2'].str
. Thanks.
I'm using pact-jvm-consumer-junit 2.2.2. When matching JSON body that contains fields starting with digits responseMatchingRules being generated incorrectly.
Example:
here is
$.body.2.str
is incorrect, because it's incorrect JS, thus on provider pact fails with meessage:To make it work i have to change match rule manually to
$.body['2'].str