jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: Test Script Recorder XML Regex Matching
Date Sat, 04 Oct 2014 12:10:34 GMT
Am 29.09.2014 um 22:32 schrieb Philippe Mouawad:
> Hi Felix,
> 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).

If no one objects, I will submit it next week.

Regards
  Felix
>
> Thanks for contributing
> Regards
>
>
> On Monday, September 29, 2014, sebb <sebbaz@gmail.com> wrote:
>
>> On 29 September 2014 15:49, Felix Schumacher
>> <felix.schumacher@internetallee.de <javascript:;>> wrote:
>>>
>>> Am 29. September 2014 12:46:19 MESZ, schrieb sebb <sebbaz@gmail.com
>> <javascript:;>>:
>>>> On 29 September 2014 11:24, Felix Schumacher
>>>> <felix.schumacher@internetallee.de <javascript:;>> wrote:
>>>>> Am 29.09.2014 11:56, schrieb sebb:
>>>>>
>>>>>> On 28 September 2014 18:11, Felix Schumacher
>>>>>> <felix.schumacher@internetallee.de <javascript:;>> 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 <javascript:;>]
>>>>>>> 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
>>>>>>> <Marijn.Wijbenga@cgpbooks.co.uk <javascript:;>> 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


Mime
View raw message