Return-Path: X-Original-To: apmail-jmeter-user-archive@www.apache.org Delivered-To: apmail-jmeter-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8A6FB1790E for ; Sat, 4 Oct 2014 18:42:18 +0000 (UTC) Received: (qmail 3675 invoked by uid 500); 4 Oct 2014 18:42:18 -0000 Delivered-To: apmail-jmeter-user-archive@jmeter.apache.org Received: (qmail 3640 invoked by uid 500); 4 Oct 2014 18:42:18 -0000 Mailing-List: contact user-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "JMeter Users List" Delivered-To: mailing list user@jmeter.apache.org Received: (qmail 3629 invoked by uid 99); 4 Oct 2014 18:42:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Oct 2014 18:42:18 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of philippe.mouawad@gmail.com designates 209.85.213.182 as permitted sender) Received: from [209.85.213.182] (HELO mail-ig0-f182.google.com) (209.85.213.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Oct 2014 18:41:51 +0000 Received: by mail-ig0-f182.google.com with SMTP id hn18so900659igb.3 for ; Sat, 04 Oct 2014 11:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/Z6l8MHMEfrPQHFFC8yg+8bKJ5QRyGOwZYKjz3Ut+UQ=; b=MT5i9egda4U0KXMtGuNjOtBzkgG6tZgdPKFuE9nF0rWpbrIlfjjx2Tisj5RcpB+bGl Q8cnmwcXM9ls4jJ4Q8r4NF/Sc5MBa+7gG2c47ZK+vmf1N9RTZLYooNLJSxt7Gftl68Yf o1axH0pQYrHDE2G6z/03N1bKMim1OnbLZgV+SiOEtqFH0nlEeAZDEyJfSyVVOf2p7KB5 bvDfiodPwcZKAk0EfHJMDx+lAgODjBZN/ou42I5nl0FUANe3SJgtjrQkBe0RmRNETuhg OqUPfOtcOkWobeey9vJysREzyJ/PvXvkw66JVLOVReSbPS9SZDuy2+5tiXjuoaMSvIc7 kRng== MIME-Version: 1.0 X-Received: by 10.50.154.5 with SMTP id vk5mr8156732igb.39.1412448110067; Sat, 04 Oct 2014 11:41:50 -0700 (PDT) Received: by 10.42.102.131 with HTTP; Sat, 4 Oct 2014 11:41:49 -0700 (PDT) In-Reply-To: <542FE3BA.7090006@internetallee.de> References: <6FF6E515E4DD154C89844BA1C2A5C0F102AB678F@MM-EXCHANGE-002.cgpbooks.cgpgroup.local> <6FF6E515E4DD154C89844BA1C2A5C0F102AB7D4B@MM-EXCHANGE-002.cgpbooks.cgpgroup.local> <5428414E.2090204@internetallee.de> <542FE3BA.7090006@internetallee.de> Date: Sat, 4 Oct 2014 20:41:49 +0200 Message-ID: Subject: Re: Test Script Recorder XML Regex Matching From: Philippe Mouawad To: JMeter Users List Content-Type: multipart/alternative; boundary=047d7bd76b98dd44b805049d3320 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bd76b98dd44b805049d3320 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 4, 2014 at 2:10 PM, Felix Schumacher < felix.schumacher@internetallee.de> wrote: > Am 29.09.2014 um 22:32 schrieb Philippe Mouawad: > >> Hi Felix, >> > Hi > I agree with sebb, patch is interesting. >> But it clearly needs to be documented (I think many users don't know about >> this feature which is really interesting) as long as code, reading patch >> first it wasn't clear for me what was intended. >> > I have added documentation to the patch and found two other things, that I > changed > in the same bug-entry. > > The random order of applying the matchers, seems a bit strange, so I > sorted the matchers > first by their length and if the matchers are the same length, then by the > name of their keys. So > the set > {'domain': 'example.com', 'server': 'www', 'regex': 'w.*' } > would be applied in the order ['domain', 'regex', 'server'] since 'domain' > has the longest matcher and > 'regex' comes before 'server' alphabetically (matchers are both the same > length). > Isn't it better to order by longest value or regexp ? www is more specific than w.* So would be : domain, server , regex > > If no one objects, I will submit it next week. > > Regards > Felix > >> >> Thanks for contributing >> Regards >> >> >> On Monday, September 29, 2014, sebb wrote: >> >> On 29 September 2014 15:49, Felix Schumacher >>> > wrote: >>> >>>> >>>> Am 29. September 2014 12:46:19 MESZ, schrieb sebb >>> >>> >: >>> >>>> On 29 September 2014 11:24, Felix Schumacher >>>>> > wrote: >>>>> >>>>>> Am 29.09.2014 11:56, schrieb sebb: >>>>>> >>>>>> On 28 September 2014 18:11, Felix Schumacher >>>>>>> > wrote: >>>>>>> >>>>>>>> Am 22.09.2014 um 11:13 schrieb Marijn Wijbenga: >>>>>>>> >>>>>>>> I've attached a jmeter project file and a html file that >>>>>>>> >>>>>>> demonstrates the >>>>> >>>>>> issue. In order to reproduce: >>>>>>>> 1. Load up xml-bug-test.jmx in jmeter. >>>>>>>> 2. Start the proxy (recorder) >>>>>>>> 3. Place xml-bug-test.html on a webserver somewhere (if on >>>>>>>> >>>>>>> localhost, do >>>>> >>>>>> not >>>>>>>> forget to remove localhost from proxy exclusion if applicable) >>>>>>>> 4. Navigate with a browser to this file (using the proxy) >>>>>>>> 5. Click both buttons in order. >>>>>>>> >>>>>>>> I could not post to a html file, hence the "test 2" button will >>>>>>>> >>>>>>> post to >>>>> >>>>>> Google. The page that loads has an error, but it still records the >>>>>>>> >>>>>>> post >>>>> >>>>>> request which is what we want to see. >>>>>>>> >>>>>>>> I also discovered that when I was using a "get" request instead >>>>>>>> >>>>>>> (I've >>>>> >>>>>> made >>>>>>>> that "test 1") then it doesn't match the first character (%). I >>>>>>>> >>>>>>> think >>>>> >>>>>> this >>>>>>>> is related. >>>>>>>> >>>>>>>> The project has a user defined variable called "TEST" with a value >>>>>>>> >>>>>>> os >>>>> >>>>>> ".*", >>>>>>>> I've ticked the box >>>>>>>> >>>>>>>> To see the results, in the recording controller the last two >>>>>>>> >>>>>>> requests >>>>> >>>>>> contain a parameter with these values: >>>>>>>> Test 1: %${TEST} >>>>>>>> Test 2: <${TEST}> >>>>>>>> >>>>>>>> Both should be just ${TEST} I believe. >>>>>>>> >>>>>>>> In the current implementation the regex will be matched against a >>>>>>>> >>>>>>> pattern >>>>> >>>>>> which looks like >>>>>>>> \b(YOUR_VALUE)\b >>>>>>>> >>>>>>>> As % and < are boundary characters they are excluded from you >>>>>>>> >>>>>>> pattern. >>>>> >>>>>> >>>>>>> This is deliberate. >>>>>>> There were problems previously as partial values were being >>>>>>> unexpectedly matched. >>>>>>> >>>>>>> See https://issues.apache.org/bugzilla/show_bug.cgi?id=52678 >>>>>>> >>>>>> >>>>>> I thougt so. Maybe, that would have been helped by adding more >>>>>> documentation, but then it is regex... >>>>>> >>>>>>> >>>>>>> I would consider this a bug, or at least documentation could be a >>>>>>>> >>>>>>> bit >>>>> >>>>>> more >>>>>>>> concise. >>>>>>>> >>>>>>> >>>>>>> Patches welcome. >>>>>>> >>>>>> A patch was attached :) >>>>>> >>>>> I meant that we would welcome a patch for the documentation. >>>>> Or at least some indication of where the documentation needs to be >>>>> updated to clarify the current behaviour. >>>>> >>>> I will look into that. >>>> >>> Thanks. >>> >>> What is your opinion on the option to detect parens and modify the regex >>>> >>> behavior? >>> >>> Looks good to me. >>> >>> The parens are very unlikely to have been used in existing tests, so >>> the modified behaviour is unlikely to break anything. >>> But we should document it in the release notes just in case. >>> >>> Felix >>>> >>>>> Attached is a patch against trunk, which checks the regex if it >>>>>>>> >>>>>>> starts >>>>> >>>>>> with >>>>>>>> '(' and ends with ')' and uses the regex as given, instead of >>>>>>>> >>>>>>> building >>>>> >>>>>> its >>>>>>>> own version. >>>>>>>> >>>>>>> >>>>>>> Please use Bugzilla for patches; it's easier to keep track of them. >>>>>>> >>>>>> I have already done so yesterday shortly after sending my mail. It is >>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=57032 >>>>>> >>>>>> What is missing from the patch is documentation. If the feature as >>>>>> >>>>> such is >>>>> >>>>>> ok, then I would add that to the existing documentation. >>>>>> >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Also, see notes below. >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: sebb [mailto:sebbaz@gmail.com ] >>>>>>>> Sent: 21 September 2014 01:52 >>>>>>>> To: JMeter Users List >>>>>>>> Subject: Re: Test Script Recorder XML Regex Matching >>>>>>>> >>>>>>>> On 19 September 2014 16:45, Marijn Wijbenga >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have an issue, which might well be a potential bug, where a >>>>>>>> >>>>>>> posted >>>>> >>>>>> value >>>>>>>> is >>>>>>>> >>>>>>>> not being matched by the Test Script Recorder's Regex Matching >>>>>>>> functionality. >>>>>>>> >>>>>>>> The request I'm recording has a post value containing XML (SAML >>>>>>>> >>>>>>> token to >>>>> >>>>>> be >>>>>>>> >>>>>>>> exact) which I'd like to replace with a variable automatically. >>>>>>>> >>>>>>>> What does the value look like? >>>>>>>> Does it have multiple lines? >>>>>>>> >>>>>>>> No, it did not have multiple lines. I did check if this was the >>>>>>>> >>>>>>> case, but >>>>> >>>>>> it >>>>>>>> wasn't >>>>>>>> >>>>>>>> For testing purposes I have configured a User Defined Variable >>>>>>>> >>>>>>> (called >>>>> >>>>>> TEST) >>>>>>>> >>>>>>>> with a value of "(?s)^.*$", I've tried "^.*$" and ".*" as well (all >>>>>>>> without >>>>>>>> double >>>>>>>> quotes). >>>>>>>> >>>>>>>> Only ".*" replaces the content with this: <${TEST}> >>>>>>>> >>>>>>>> That does not make sense. >>>>>>>> ".*" will match everything, including < and >, so the content would >>>>>>>> become >>>>>>>> ${TEST} >>>>>>>> >>>>>>>> I know. It doesn't really. Hence I think this might be a bug. >>>>>>>> >>>>>>>> I've tried other expressions as well and I'm able to match anything >>>>>>>> within >>>>>>>> the >>>>>>>> >>>>>>>> <> characters, but not those characters itself. >>>>>>>> >>>>>>>> Again, that does not make sense. >>>>>>>> >>>>>>>> The weird thing is, that inside the outer <> characters there are >>>>>>>> >>>>>>> other >>>>> >>>>>> <> >>>>>>>> characters that are matched fine. It's just the first and last >>>>>>>> >>>>>>> character. >>>>> >>>>>> Does anyone else have experienced the same thing, or is this a >>>>>>>> >>>>>>> known >>>>> >>>>>> issue? >>>>>>>> >>>>>>>> It is not a known issue, and may not even be an issue. >>>>>>>> >>>>>>>> Or should I post this in the developer's mailing list? >>>>>>>> >>>>>>>> No, the developers all follow this list. >>>>>>>> >>>>>>>> Great, please see attachment for an example. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org > For additional commands, e-mail: user-help@jmeter.apache.org > > -- Cordialement. Philippe Mouawad. --047d7bd76b98dd44b805049d3320--