jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: [Bug 54189] New: Add a function to quote ORO regexp meta characters
Date Thu, 22 Nov 2012 12:48:54 GMT
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

Regarding ORO , I agree with you but what about compatibility ? it would be
an option of regexp components ?

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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message