Am 29. September 2014 12:46:19 MESZ, schrieb sebb <[email protected]>:
>On 29 September 2014 11:24, Felix Schumacher
><[email protected]> wrote:
>> Am 29.09.2014 11:56, schrieb sebb:
>>
>>> On 28 September 2014 18:11, Felix Schumacher
>>> <[email protected]> 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.
What is your opinion on the option to detect parens and modify the regex
behavior?
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:[email protected]]
>>>> 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
>>>> <[email protected]> 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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>>>
>---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>>>
>>>>
>---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
