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
<hartmut.honi...@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



Attachment: OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to