You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "Honisch, Hartmut" <ha...@festo.com.INVALID> on 2022/02/17 22:12:43 UTC

Response Assertion: extended regex ignore case syntax not working as documented

Hi team,

I noticed that regex patterns in "Response Assertions" using "(?i)" and "(?-i)" to enable / disable case insensitive matching for certain parts of the regex pattern don't work as they're supposed to.
For example the regex "(?i)apple(?-i) Pie" does NOT match "ApPLe Pie", even though it should according to JMeter documentation, see https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion.

Looks like that particular regex feature in Response Assertions has never worked as documented. Unfortunately, that part of JMeter uses the old Jakarta ORO regex parser (https://jakarta.apache.org/oro/) which was retired in 2010, so it won't be fixed there. I guess JMeter would have to replace the old ORO regex parser with Java's built-in regex implementation - which is used in other places like the "View Results Tree" listener "find" function BTW.

I've filed a bug (https://bz.apache.org/bugzilla/show_bug.cgi?id=65883), but I was asked to take the issue to the mailing list, because switching from ORO regex parser to Java regex parser will certainly cause some existing regex's to behave differently. Nevertheless, IMHO it would be a good idea to remove the ORO parser from JMeter with the next major release (6.0) - if only because using an abandoned library in your application is never a good thing for obvious reasons.

Any thoughts on this?

Regards
Hartmut



Re: Response Assertion: extended regex ignore case syntax not working as documented

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
On Fri, Feb 18, 2022 at 12:38 PM Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

> Hi Philippe,
>
> I told Hartmut to take the discussion on list, as I think it has a wider
> audience and changing the implementation could introduce a changed
> behaviour in test plans.
>
Yes good idea

>
> I hadn't thought of Bug 57672, but remembered an older discussion on
> (dev?) mailing list, where the possible breaking changes where weighed
> higher than the advantages of getting rid of an dependency and having a
> richer implementation of a regex parser.
>
Possibly, it's a bit far for my memory :-)

>
> Vladimir proposed a sliding change of wrapping the ORO instances for one
> of the next releases with a configurable switch to let users decide on
> the actual implementation and later start deprecating ORO and even later
> removing it.

Yes it's a good idea


> I think that is a valid approach and I second your
> statement of volunteer time, that we would gladly accept :)
>
:-)

>
> Kind Regards
>
>   Felix
>
> Am 18.02.22 um 08:54 schrieb Philippe Mouawad:
> > Hello,
> >
> > The migration from Oro to Java regex is identified for a while now under:
> >
> > - https://bz.apache.org/bugzilla/show_bug.cgi?id=57672
> >
> > Still, as you know, this project is based on volunteers work.
> > If you feel like contributing this enhancement you'll be welcome.
> > Otherwise you may have to wait a bit, although change can happen fast :-)
> >
> >
> > Regards
> >
> > On Thu, Feb 17, 2022 at 11:13 PM Honisch, Hartmut
> > <ha...@festo.com.invalid> wrote:
> >
> >> Hi team,
> >>
> >> I noticed that regex patterns in "Response Assertions" using "(?i)" and
> >> "(?-i)" to enable / disable case insensitive matching for certain parts
> of
> >> the regex pattern don't work as they're supposed to.
> >> For example the regex "(?i)apple(?-i) Pie" does NOT match "ApPLe Pie",
> >> even though it should according to JMeter documentation, see
> >>
> https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
> >> .
> >>
> >> Looks like that particular regex feature in Response Assertions has
> never
> >> worked as documented. Unfortunately, that part of JMeter uses the old
> >> Jakarta ORO regex parser (https://jakarta.apache.org/oro/) which was
> >> retired in 2010, so it won't be fixed there. I guess JMeter would have
> to
> >> replace the old ORO regex parser with Java's built-in regex
> implementation
> >> - which is used in other places like the "View Results Tree" listener
> >> "find" function BTW.
> >>
> >> I've filed a bug (https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
> ),
> >> but I was asked to take the issue to the mailing list, because switching
> >> from ORO regex parser to Java regex parser will certainly cause some
> >> existing regex's to behave differently. Nevertheless, IMHO it would be a
> >> good idea to remove the ORO parser from JMeter with the next major
> release
> >> (6.0) - if only because using an abandoned library in your application
> is
> >> never a good thing for obvious reasons.
> >>
> >> Any thoughts on this?
> >>
> >> Regards
> >> Hartmut
> >>
> >>
> >>
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Response Assertion: extended regex ignore case syntax not working as documented

Posted by Felix Schumacher <fe...@internetallee.de>.
Hi Philippe,

I told Hartmut to take the discussion on list, as I think it has a wider 
audience and changing the implementation could introduce a changed 
behaviour in test plans.

I hadn't thought of Bug 57672, but remembered an older discussion on 
(dev?) mailing list, where the possible breaking changes where weighed 
higher than the advantages of getting rid of an dependency and having a 
richer implementation of a regex parser.

Vladimir proposed a sliding change of wrapping the ORO instances for one 
of the next releases with a configurable switch to let users decide on 
the actual implementation and later start deprecating ORO and even later 
removing it. I think that is a valid approach and I second your 
statement of volunteer time, that we would gladly accept :)

Kind Regards

  Felix

Am 18.02.22 um 08:54 schrieb Philippe Mouawad:
> Hello,
>
> The migration from Oro to Java regex is identified for a while now under:
>
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=57672
>
> Still, as you know, this project is based on volunteers work.
> If you feel like contributing this enhancement you'll be welcome.
> Otherwise you may have to wait a bit, although change can happen fast :-)
>
>
> Regards
>
> On Thu, Feb 17, 2022 at 11:13 PM Honisch, Hartmut
> <ha...@festo.com.invalid> wrote:
>
>> Hi team,
>>
>> I noticed that regex patterns in "Response Assertions" using "(?i)" and
>> "(?-i)" to enable / disable case insensitive matching for certain parts of
>> the regex pattern don't work as they're supposed to.
>> For example the regex "(?i)apple(?-i) Pie" does NOT match "ApPLe Pie",
>> even though it should according to JMeter documentation, see
>> https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
>> .
>>
>> Looks like that particular regex feature in Response Assertions has never
>> worked as documented. Unfortunately, that part of JMeter uses the old
>> Jakarta ORO regex parser (https://jakarta.apache.org/oro/) which was
>> retired in 2010, so it won't be fixed there. I guess JMeter would have to
>> replace the old ORO regex parser with Java's built-in regex implementation
>> - which is used in other places like the "View Results Tree" listener
>> "find" function BTW.
>>
>> I've filed a bug (https://bz.apache.org/bugzilla/show_bug.cgi?id=65883),
>> but I was asked to take the issue to the mailing list, because switching
>> from ORO regex parser to Java regex parser will certainly cause some
>> existing regex's to behave differently. Nevertheless, IMHO it would be a
>> good idea to remove the ORO parser from JMeter with the next major release
>> (6.0) - if only because using an abandoned library in your application is
>> never a good thing for obvious reasons.
>>
>> Any thoughts on this?
>>
>> Regards
>> Hartmut
>>
>>
>>

Re: Response Assertion: extended regex ignore case syntax not working as documented

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello,

The migration from Oro to Java regex is identified for a while now under:

- https://bz.apache.org/bugzilla/show_bug.cgi?id=57672

Still, as you know, this project is based on volunteers work.
If you feel like contributing this enhancement you'll be welcome.
Otherwise you may have to wait a bit, although change can happen fast :-)


Regards

On Thu, Feb 17, 2022 at 11:13 PM Honisch, Hartmut
<ha...@festo.com.invalid> wrote:

> Hi team,
>
> I noticed that regex patterns in "Response Assertions" using "(?i)" and
> "(?-i)" to enable / disable case insensitive matching for certain parts of
> the regex pattern don't work as they're supposed to.
> For example the regex "(?i)apple(?-i) Pie" does NOT match "ApPLe Pie",
> even though it should according to JMeter documentation, see
> https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
> .
>
> Looks like that particular regex feature in Response Assertions has never
> worked as documented. Unfortunately, that part of JMeter uses the old
> Jakarta ORO regex parser (https://jakarta.apache.org/oro/) which was
> retired in 2010, so it won't be fixed there. I guess JMeter would have to
> replace the old ORO regex parser with Java's built-in regex implementation
> - which is used in other places like the "View Results Tree" listener
> "find" function BTW.
>
> I've filed a bug (https://bz.apache.org/bugzilla/show_bug.cgi?id=65883),
> but I was asked to take the issue to the mailing list, because switching
> from ORO regex parser to Java regex parser will certainly cause some
> existing regex's to behave differently. Nevertheless, IMHO it would be a
> good idea to remove the ORO parser from JMeter with the next major release
> (6.0) - if only because using an abandoned library in your application is
> never a good thing for obvious reasons.
>
> Any thoughts on this?
>
> Regards
> Hartmut
>
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie