You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by John Kavadias <jo...@nstc.nec.com.au> on 2002/08/23 08:02:21 UTC

Problems using [0-9]+ and \d+ and \w+ with __regexFunction

Hi.

JMeter version: latest CVS version as of 2002-08-23 01:33 UTC

ORO .jar file is for version 2.0.1 in JMeter's lib directory. I have not simply tried dropping in version 2.0.6 in its place.

I have been experimenting incrementally with ${__regexFunction(...)} to set the value of a parameter in an HTTP request, using the content of the preceding HTTP response.

I found that specifying the following as my RE produces matches on the response content:

tabindex="[0-9][0-9]*"

However the following, Perl5 compatible, simpler, shorter RE does not produce any matches on the response content:

tabindex="[0-9]+"

I generated the HTTP parameter value (ie the ${__regex...} string) using the function helper dialog of JMeter.

The RE's I used are those given above. The other parameters for the __regexFunction were:

::$0$::
ALL
ZZZ
NOMATCH
tiREF

With the first RE using [0-9][0-9]* I got as "output" all the matches concatenated:

::tabindex="1"::::tabindex="2"::::tabindex="3"::::tabindex="4"::

Notice the ZZZ was not used to separate the matches. It should be when ALL is specified for arg 3 of __regexFunction.

With the second RE using [0-9]+ I got as "ouptut":

NOMATCH

When I use \d\d* in the RE I get matches. When I use \d+ in the RE I get NOMATCH.

Thanks for any comments,
John Kavadias    johnk@nstc.nec.com.au

AW: jmeter help

Posted by Wolfram Rittmeyer <w....@proplant.de>.
Yes, Bala,

that's right. There are differences - the website isn't updated as often as
JMeter itself. You should use the usermanual that is part of your
JMeter-download instead.

To use the MailerVisualizer you have to add the activation.jar and the
mail.jar (available from the SUN-website as JavaActivationFramework and
JavaMail) to your lib-directory prior to building JMeter.

Regarding your need for help: It would be better, if you could describe what
exactly you are missing and what exactly troubles you. At least I didn't get
what actually hinders you from using JMeter.

Greetings,

Wolfram


-------------------------
Original message by Bala:
Hi,

I am a new B to this list.
Last two days i was trying to send the mail to this list.
But i wasn't able to do this..
I got only replies from the admin of the apache for each mail.
Thats why i am sending mail thro' reply.
If i am doing wrong thing, please forgive me.
I am using jmeter 1.7
In the jmeter User manual in apache website.
I am able to see the following listener:
Mailer Visualizer
Aggregate Report

And also there is lot of differnce between that user manual and jmeter.
please tell me why it is so.
Otherwise help me to do load testing thro' jmeter 1.7.
I want to get a numerical output of the maximum reliability of my server.
Expecting help immediately.

with regards,
bala


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

jmeter help

Posted by balamurugan <ba...@unilogin.com>.
Hi,

I am a new B to this list.
Last two days i was trying to send the mail to this list.
But i wasn't able to do this..
I got only replies from the admin of the apache for each mail.
Thats why i am sending mail thro' reply.
If i am doing wrong thing, please forgive me.
I am using jmeter 1.7
In the jmeter User manual in apache website.
I am able to see the following listener:
Mailer Visualizer
Aggregate Report

And also there is lot of differnce between that user manual and jmeter.
please tell me why it is so.
Otherwise help me to do load testing thro' jmeter 1.7.
I want to get a numerical output of the maximum reliability of my server.
Expecting help immediately.

with regards,
bala


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Problems using [0-9]+ and \d+ and \w+ with __regexFunction

Posted by Mike Stover <ms...@apache.org>.
John,
      This all sounds like an interesting bug.  Time for me to play with it.

-Mike

On 26 Aug 2002 at 19:43, John Kavadias wrote:

> Hi Mike,
> 
> > I use the "+" all the time in my regex's.  I suspect that what you have done is created the function in the function dialog, and then later modified it directly.  This won't work.
> 
> > For instance, if you create the function ${__regexFunction(%5Cd*,%240%24,ALL,,,)}, and then modify it to: ${__regexFunction(%5Cd+,%240%24,ALL,,,)}
> (just changed the '*' to '+'), this won't work.
> 
> I can put this concern to rest. The function was re-generated each time using the helper dialog's Generate. I kept the dialog open while tweaking function arguments and running test plans.
> 
> However you show encoding from the Function Helper Dialog's Generate in your example.
> 
> This triggered a thought: I did NOT have 'Encode?' ticked for the parameter whose value is the generated (ie argument list encoded) function string.
> 
> I have found that when 'Encode?' is NOT ticked, I get the failure I described in the original posting. When 'Encode?' IS ticked, it all works (the '+' makes it through to the regex invocation).
> 
> The function argument list is encoded once by Function Helper Dialog's Generate, as you advise. '+' in the Function Helper Dialog's regex field becomes %2B in the encoded/generated function string.
> 
> Pasting that string into an HTTP Request parameter value where 'Encode?' IS ticked produces %252B in the XML file for the test plan. The double encoding of the function argument list makes the HTTP request parameter value work as a regex invocation. It also makes the regex work across file 
saves/loads for the test plan.
> 
> Here is my UNencoded __regexFunction:
> 
> ${__regexFunction(productId=(\w+)\W,$1$,RAND,,NOMATCH,productIdREF)}
> 
> Here is a .jmx save file fragment when the above is generated, then pasted into an HTTP Request parameter value which IS marked as Encoded:
> 
> <testelement class="org.apache.jmeter.protocol.http.util.HTTPArgument">
> <property name="HTTPArgument.always_encode">true</property>
> <property name="Argument.name">productId</property>
> <property name="HTTPArgument.encoded_value">%24%7B__regexFunction%28productId%253D%2528%255Cw%252B%2529%255CW%2C%25241%2524%2CRAND%2C%2CNOMATCH%2CproductIdREF%29%7D</property>
> <property name="HTTPArgument.encoded_name">productId</property>
> <property name="Argument.value">${__regexFunction(productId%3D%28%5Cw%2B%29%5CW,%241%24,RAND,,NOMATCH,productIdREF)}</property>
> </testelement>
> 
> 
> Here is a .jmx save file fragment when the above is generated, then pasted into an HTTP Request parameter value which is NOT marked as Encoded:
> 
> <testelement class="org.apache.jmeter.protocol.http.util.HTTPArgument">
> <property name="HTTPArgument.always_encode">false</property>
> <property name="Argument.name">productId</property>
> <property name="HTTPArgument.encoded_value">${__regexFunction(productId=(\w+)\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
> <property name="HTTPArgument.encoded_name">productId</property>
> <property name="Argument.value">${__regexFunction(productId=(\w+)\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
> </testelement>
> 
> Saving the test plan removes the encoding performed by Function Helper Dialog's Generate in this case.
> 
> 
> [[ Aside: I closed the file from which I got the above fragments, opened it again and saved it to a new file name. A very interesting observation on the new file: the '\w+' in the parameter value has become '\w ':
> 
> <testelement class="org.apache.jmeter.protocol.http.util.HTTPArgument">
> <property name="HTTPArgument.always_encode">false</property>
> <property name="Argument.name">productId</property>
> <property name="HTTPArgument.encoded_value">${__regexFunction(productId=(\w )\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
> <property name="HTTPArgument.encoded_name">productId</property>
> <property name="Argument.value">${__regexFunction(productId=(\w )\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
> </testelement>
> 
> The encoded version of the __regexFunction in the same file was unchanged in the new save file. This happens on both my Solaris and WinNT installations/builds of JMeter. ]]
> 
> 
> When 'Encode?' is ticked it also affects how the 'substitution value' (argument 2 of __regexFunction) becomes the actual value provided in the HTTP GET URL. For example if : is part of the substitution value, you get : if 'Encode?' is NOT ticked and %3A if 'Encode?' IS ticked.
> 
> This means you cannot use a function string which requires argument encoding as the 'value' of an HTTP request parameter that you want to have UNencoded.
> 
> > The other issue is probably a bug (using the ALL option), which I'll look into.
> 
> Thanks for your response and your work.
> Further comments appreciated.
> John Kavadias    johnk@nstc.nec.com.au



--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Problems using [0-9]+ and \d+ and \w+ with __regexFunction

Posted by John Kavadias <jo...@nstc.nec.com.au>.
Hi Mike,

> I use the "+" all the time in my regex's.  I suspect that what you have done is created the function in the function dialog, and then later modified it directly.  This won't work.

> For instance, if you create the function ${__regexFunction(%5Cd*,%240%24,ALL,,,)}, and then modify it to: ${__regexFunction(%5Cd+,%240%24,ALL,,,)}
(just changed the '*' to '+'), this won't work.

I can put this concern to rest. The function was re-generated each time using the helper dialog's Generate. I kept the dialog open while tweaking function arguments and running test plans.

However you show encoding from the Function Helper Dialog's Generate in your example.

This triggered a thought: I did NOT have 'Encode?' ticked for the parameter whose value is the generated (ie argument list encoded) function string.

I have found that when 'Encode?' is NOT ticked, I get the failure I described in the original posting. When 'Encode?' IS ticked, it all works (the '+' makes it through to the regex invocation).

The function argument list is encoded once by Function Helper Dialog's Generate, as you advise. '+' in the Function Helper Dialog's regex field becomes %2B in the encoded/generated function string.

Pasting that string into an HTTP Request parameter value where 'Encode?' IS ticked produces %252B in the XML file for the test plan. The double encoding of the function argument list makes the HTTP request parameter value work as a regex invocation. It also makes the regex work across file saves/loads for the test plan.

Here is my UNencoded __regexFunction:

${__regexFunction(productId=(\w+)\W,$1$,RAND,,NOMATCH,productIdREF)}

Here is a .jmx save file fragment when the above is generated, then pasted into an HTTP Request parameter value which IS marked as Encoded:

<testelement class="org.apache.jmeter.protocol.http.util.HTTPArgument">
<property name="HTTPArgument.always_encode">true</property>
<property name="Argument.name">productId</property>
<property name="HTTPArgument.encoded_value">%24%7B__regexFunction%28productId%253D%2528%255Cw%252B%2529%255CW%2C%25241%2524%2CRAND%2C%2CNOMATCH%2CproductIdREF%29%7D</property>
<property name="HTTPArgument.encoded_name">productId</property>
<property name="Argument.value">${__regexFunction(productId%3D%28%5Cw%2B%29%5CW,%241%24,RAND,,NOMATCH,productIdREF)}</property>
</testelement>


Here is a .jmx save file fragment when the above is generated, then pasted into an HTTP Request parameter value which is NOT marked as Encoded:

<testelement class="org.apache.jmeter.protocol.http.util.HTTPArgument">
<property name="HTTPArgument.always_encode">false</property>
<property name="Argument.name">productId</property>
<property name="HTTPArgument.encoded_value">${__regexFunction(productId=(\w+)\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
<property name="HTTPArgument.encoded_name">productId</property>
<property name="Argument.value">${__regexFunction(productId=(\w+)\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
</testelement>

Saving the test plan removes the encoding performed by Function Helper Dialog's Generate in this case.


[[ Aside: I closed the file from which I got the above fragments, opened it again and saved it to a new file name. A very interesting observation on the new file: the '\w+' in the parameter value has become '\w ':

<testelement class="org.apache.jmeter.protocol.http.util.HTTPArgument">
<property name="HTTPArgument.always_encode">false</property>
<property name="Argument.name">productId</property>
<property name="HTTPArgument.encoded_value">${__regexFunction(productId=(\w )\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
<property name="HTTPArgument.encoded_name">productId</property>
<property name="Argument.value">${__regexFunction(productId=(\w )\W,$1$,RAND,,NOMATCH,productIdREF)}</property>
</testelement>

The encoded version of the __regexFunction in the same file was unchanged in the new save file. This happens on both my Solaris and WinNT installations/builds of JMeter. ]]


When 'Encode?' is ticked it also affects how the 'substitution value' (argument 2 of __regexFunction) becomes the actual value provided in the HTTP GET URL. For example if : is part of the substitution value, you get : if 'Encode?' is NOT ticked and %3A if 'Encode?' IS ticked.

This means you cannot use a function string which requires argument encoding as the 'value' of an HTTP request parameter that you want to have UNencoded.

> The other issue is probably a bug (using the ALL option), which I'll look into.

Thanks for your response and your work.
Further comments appreciated.
John Kavadias    johnk@nstc.nec.com.au

Re: Problems using [0-9]+ and \d+ and \w+ with __regexFunction

Posted by Mike Stover <ms...@apache.org>.
I use the "+" all the time in my regex's.  I suspect that what you have done is created the 
function in the function dialog, and then later modified it directly.  This won't work.

For instance, if you create the function ${__regexFunction(%5Cd*,%240%24,ALL,,,)}, and 
then modify it to: ${__regexFunction(%5Cd+,%240%24,ALL,,,)}
(just changed the '*' to '+'), this won't work.

The value of the regular expression is assumed to be URLEncoded.  A '+' decodes into a 
space.  This is why one should always go back to the function helper to change the function.  
It is inconvenient, and I am thinking of ways to improved that.

The other issue is probably a bug (using the ALL option), which I'll look into.

-Mike

On 23 Aug 2002 at 16:02, John Kavadias wrote:

> Hi.
> 
> JMeter version: latest CVS version as of 2002-08-23 01:33 UTC
> 
> ORO .jar file is for version 2.0.1 in JMeter's lib directory. I have not simply tried dropping in version 2.0.6 in its place.
> 
> I have been experimenting incrementally with ${__regexFunction(...)} to set the value of a parameter in an HTTP request, using the content of the preceding HTTP response.
> 
> I found that specifying the following as my RE produces matches on the response content:
> 
> tabindex="[0-9][0-9]*"
> 
> However the following, Perl5 compatible, simpler, shorter RE does not produce any matches on the response content:
> 
> tabindex="[0-9]+"
> 
> I generated the HTTP parameter value (ie the ${__regex...} string) using the function helper dialog of JMeter.
> 
> The RE's I used are those given above. The other parameters for the __regexFunction were:
> 
> ::$0$::
> ALL
> ZZZ
> NOMATCH
> tiREF
> 
> With the first RE using [0-9][0-9]* I got as "output" all the matches concatenated:
> 
> ::tabindex="1"::::tabindex="2"::::tabindex="3"::::tabindex="4"::
> 
> Notice the ZZZ was not used to separate the matches. It should be when ALL is specified for arg 3 of __regexFunction.
> 
> With the second RE using [0-9]+ I got as "ouptut":
> 
> NOMATCH
> 
> When I use \d\d* in the RE I get matches. When I use \d+ in the RE I get NOMATCH.
> 
> Thanks for any comments,
> John Kavadias    johnk@nstc.nec.com.au



--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>