jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Bug 54189] New: Add a function to quote ORO regexp meta characters
Date Thu, 22 Nov 2012 23:03:40 GMT
On 22 November 2012 20:35, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> On Thu, Nov 22, 2012 at 2:09 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 22 November 2012 12:48, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>> > Hello Sebb,
>> > I already implemented it, I can remove it if you dislike it.
>> >
>> > I implemented it to answer initial requirement mentionned here:
>> >
>> >    - https://issues.apache.org/bugzilla/show_bug.cgi?id=54176
>> >    -
>> >
>> http://stackoverflow.com/questions/13472646/how-to-escape-regular-expression-characters-from-variable-in-jmeter
>>
>> I'd not realised there was a quoteMeta() method already.
>>
>> However, using the function is very awkward; it would be better to
>> implement \Q \E.
>>
> Why is it awkward ?
>

Which is easier:

${____escapeOroRegexpChars(a.b)}

or

\Qa.b\E

Even if the function were renamed as

__QU

it would still be relatively awkward to use.


>
>> AFAICT would not be difficult; just need to watch out for \\Q versus
>> \Q. Same for \E.
>> And then ensure that the method is invoked whenever strings are passed to
>> ORO.
>>
>> But there will still be other features of Java regexes (e.g.
>> look-behind) that people will try to use and wonder why JMeter does
>> not work.
>>
>> > Regarding ORO , I agree with you but what about compatibility ?
>>
>> I'm not sure what compatibility issues you are referring to.
>>
>> Are regexp syntax the same ?
>
>> > it would be an option of regexp components ?
>>
>> Not sure what you mean here.
>>
> If syntax is different, then we would need that no ? but if they are
> exactly the same then no need for it

The basic syntax is the same, but there are some features such as
look-behind which are not implemented.

If there are any constructs that currently mean nothing in ORO but
have meaning in Java regexes there might be a problem.

For example \Q and \E mean nothing special in ORO, but they do in Java.

However, in ORO there is no need to use \ before Q, so why would a
test plan use it? Seems very unlikely that any problems would arise
from this.

In the case of look-behind - (?<=regexp) - the syntax causes ORO to
throw an error, so it cannot be used in existing test plans.

I think it's very unlikely that dropping support for ORO would cause
test plans to fail.

However, we do still need to check the performance aspect, because
that can be important for tests.

>>
>> > Regards
>> > Philippe
>> >
>> >
>> > On Thu, Nov 22, 2012 at 1:41 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 22 November 2012 12:07,  <bugzilla@apache.org> wrote:
>> >> > https://issues.apache.org/bugzilla/show_bug.cgi?id=54189
>> >> >
>> >> >             Bug ID: 54189
>> >> >            Summary: Add a function to quote ORO regexp meta characters
>> >> >            Product: JMeter
>> >> >            Version: 2.8
>> >> >           Hardware: All
>> >> >                 OS: All
>> >> >             Status: NEW
>> >> >           Severity: enhancement
>> >> >           Priority: P2
>> >> >          Component: Main
>> >> >           Assignee: issues@jmeter.apache.org
>> >> >           Reporter: p.mouawad@ubik-ingenierie.com
>> >> >     Classification: Unclassified
>> >> >
>> >> > This function would do the equivalent of \Q \E for ORO Regexp as it
>> does
>> >> not
>> >> > exist in it.
>> >>
>> >> Quoting strings won't be trivial.
>> >> Also I'm not sure how one would use it in test plans - seems like it
>> >> would be very awkward to use.
>> >> A better solution might be to implement \Q \E processing, e.g. by
>> >> converting the string if it contains \Q and \E.
>> >> [This would require the additiional step of first splitting the string
>> >> into chunks delimited by \Q and \E]
>> >>
>> >> However the changes would be a waste of time if we decide to replace
>> >> ORO with Java regex processing.
>> >>
>> >> AIUI ORO was used originally because it was faster than the Java
>> >> equivalent; however that was a long time ago.
>> >> It's likely that the Java implementation has been improved since then.
>> >> There may possibly be some advantages of the ORO implementation, but I
>> >> can't think of any off-hand.
>> >>
>> >> I think we need to look at whether ORO is still needed before trying
>> >> to fix any of its omissions.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message