On 29 September 2014 11:24, Felix Schumacher
<felix.schumac...@internetallee.de> wrote:
> Am 29.09.2014 11:56, schrieb sebb:
>
>> On 28 September 2014 18:11, Felix Schumacher
>> <felix.schumac...@internetallee.de> 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.
>>
>>> 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:seb...@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
>>> <marijn.wijbe...@cgpbooks.co.uk> 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-unsubscr...@jmeter.apache.org
>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>>> For additional commands, e-mail: user-h...@jmeter.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
>> For additional commands, e-mail: user-h...@jmeter.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
