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 <[email protected]> wrote:
On 29 September 2014 15:49, Felix Schumacher
<[email protected] <javascript:;>> wrote:
Am 29. September 2014 12:46:19 MESZ, schrieb sebb <[email protected]
<javascript:;>>:
On 29 September 2014 11:24, Felix Schumacher
<[email protected] <javascript:;>> wrote:
Am 29.09.2014 11:56, schrieb sebb:
On 28 September 2014 18:11, Felix Schumacher
<[email protected] <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:[email protected] <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
<[email protected] <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: [email protected]
For additional commands, e-mail: [email protected]
