You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2016/11/29 19:24:43 UTC

PR235 and matching behaviour

Hi all,

I had a look at PR 235 and it addresses a valid bug. But I think the bug 
goes a bit further than that.

The patch addresses the case, where the processor first matches multiple 
things with JSON Processor and after that gets an empty input for the 
matching. In that case JMeter will leave the old values in 
refname_matchNr and refname_<idx>.

If on the other hand the first match is again a multi match and the 
second gets processed with a matchnumber of "0". Then it gets a bit 
weird. refname_matchNr will be set to the number of found elements, but 
no elements will be stored in refname_<idx>.

Thinking about this, I believe the correct result in both cases would be 
to have no refname_matchNr and no refname_<idx> left in the vars.

What do you think?

Regards,

  Felix

Re: PR235 and matching behaviour

Posted by Felix Schumacher <fe...@internetallee.de>.
Am 29.11.2016 um 20:26 schrieb Philippe Mouawad:
> On Tue, Nov 29, 2016 at 8:24 PM, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Hi all,
>>
>> I had a look at PR 235 and it addresses a valid bug. But I think the bug
>> goes a bit further than that.
>>
>> The patch addresses the case, where the processor first matches multiple
>> things with JSON Processor and after that gets an empty input for the
>> matching. In that case JMeter will leave the old values in refname_matchNr
>> and refname_<idx>.
>>
>> If on the other hand the first match is again a multi match and the second
>> gets processed with a matchnumber of "0". Then it gets a bit weird.
>> refname_matchNr will be set to the number of found elements, but no
>> elements will be stored in refname_<idx>.
>>
>> Thinking about this, I believe the correct result in both cases would be
>> to have no refname_matchNr and no refname_<idx> left in the vars.
>>
>> What do you think?
>>
>> I agree with your proposal
Ok, but when I implement the proposed behaviour, I get a unit test 
failure in TestJSONPostProcessor#testBug59609 where it is explicitly 
checked for refname_matchNr == 1 with matchnumber = "0".

I think the unit test is wrong and I would like to change it, to 
explicitly check that refname_matchNr is null.

What do you think?

Felix

>> Regards,
>>
>>   Felix
>>
>>
>

Re: PR235 and matching behaviour

Posted by Philippe Mouawad <ph...@gmail.com>.
On Tue, Nov 29, 2016 at 8:24 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

> Hi all,
>
> I had a look at PR 235 and it addresses a valid bug. But I think the bug
> goes a bit further than that.
>
> The patch addresses the case, where the processor first matches multiple
> things with JSON Processor and after that gets an empty input for the
> matching. In that case JMeter will leave the old values in refname_matchNr
> and refname_<idx>.
>
> If on the other hand the first match is again a multi match and the second
> gets processed with a matchnumber of "0". Then it gets a bit weird.
> refname_matchNr will be set to the number of found elements, but no
> elements will be stored in refname_<idx>.
>
> Thinking about this, I believe the correct result in both cases would be
> to have no refname_matchNr and no refname_<idx> left in the vars.
>
> What do you think?
>
> I agree with your proposal

> Regards,
>
>  Felix
>
>


-- 
Cordialement.
Philippe Mouawad.