On Thu, Nov 22, 2012 at 2:09 PM, sebb <[email protected]> wrote: > On 22 November 2012 12:48, Philippe Mouawad <[email protected]> > 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 ?
> 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 > > > Regards > > Philippe > > > > > > On Thu, Nov 22, 2012 at 1:41 PM, sebb <[email protected]> wrote: > > > >> On 22 November 2012 12:07, <[email protected]> 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: [email protected] > >> > Reporter: [email protected] > >> > 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.
