You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2022/02/15 09:17:52 UTC
[Bug 65883] New: Response Assertion: extended RegEx ignore case syntax broken / not working as documented
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
Bug ID: 65883
Summary: Response Assertion: extended RegEx ignore case syntax
broken / not working as documented
Product: JMeter
Version: 5.4.3
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Main
Assignee: issues@jmeter.apache.org
Reporter: Hartmut.Honisch@festo.com
Target Milestone: JMETER_5.5
Created attachment 38191
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38191&action=edit
Sample test plan demonstrating the issue
I seems that as of JMeter 5.4.3, extended 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 a Response Assertion using the pattern "(?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.
I've attached a short sample test plan containing two JSR223 samplers with
response assertions to demonstrate the error. It shows that
a) "(?i)apple(?-i) Pie" DOES NOT match a response "ApPLe Pie" (even though it
should)
b) "(?i)apple Pie" DOES match a response "ApPLe Pie" (correct behaviour, just
double-checking)
Note that the regex "(?i)apple(?-i) Pie" matches "ApPLe Pie" correctly when
used interactively in "View Results Tree" => select sampler => Response data =>
Response Body => Find (check "RegEx")
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
--- Comment #3 from hhon <Ha...@festo.com> ---
JMeter Response Assertion uses Jakarta ORO for regex matching. Jakarta ORO was
retired in 2010 according to https://jakarta.apache.org/oro/ .
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #4 from Felix Schumacher <fe...@internetallee.de> ---
I asked, as I thought your comment "as of JMeter 5.4.3" would mean, that it
worked before, which would have been strange. As you noted, that part of JMeter
uses the old ORO regex parser and has not been touched for a long time.
It was discussed a while ago to replace the ORO regex parser with the built-in
Java regex parser. My last impression on that line was, that it seemed to risky
to change the behaviour, as it could introduce changes in test plan that were
run on older JMeter versions and are compared to recent ones.
Would you mind to take this issue to the users or dev mailing list? I am not
sure, we should change it just now, as we are shortly (famous last words)
preparing for 5.5 release. But it might be a good move for a 6.0.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
Status|NEW |NEEDINFO
--- Comment #1 from Felix Schumacher <fe...@internetallee.de> ---
Which is the last version this worked for you?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
hhon <Ha...@festo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from hhon <Ha...@festo.com> ---
I'm not sure this ever worked in any version of JMeter. I checked v2.9
(released in 2013) and v3.3 (released in 2017): Same behaviour.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
hhon <Ha...@festo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #5 from hhon <Ha...@festo.com> ---
I've sent an e-mail to the users mailing list. IMHO it would be a good idea to
remove the ORO parser from JMeter in the next major release, since it's never a
good thing to have a dependendy to an abandoned library.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #7 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello,
Yes, it's a good approach.
Note there is this enhancement Bug 57672 that looks a better candidate for this
discussion.
*** This bug has been marked as a duplicate of bug 57672 ***
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65883] Response Assertion: extended RegEx ignore case syntax broken / not working as documented
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65883
--- Comment #6 from Vladimir Sitnikov <si...@gmail.com> ---
What if we add a "temporary" property to flip between library implementations.
For instance:
5.5 -- add a property, keep using ORO by default, print deprecation warnings
when affected component is used
5.8 -- start using Java implementation by default, keep printing the warning,
allow fallback via property
6.5 -- stop printing the warning
7.0 -- remove ORO
WDYT?
--
You are receiving this mail because:
You are the assignee for the bug.