DO NOT REPLY [Bug 12220] New: - Problem expanding multiple JMeter ${} in Path of HTTP Request

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12220>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12220

Problem expanding multiple JMeter ${} in Path of HTTP Request

           Summary: Problem expanding multiple JMeter ${} in Path of HTTP
                    Request
           Product: JMeter
           Version: 1.7.3
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Main
        AssignedTo: jmeter-dev@jakarta.apache.org
        ReportedBy: johnk@nstc.nec.com.au


My version of JMeter is a CVS checkout at Fri Aug 23 01:33:17  2002  UTC/GMT.

I am trying to parameterise my test plans as much as possible using the
User Variables that may be set for a Test Plan.

I have a standard web context under which my web application can be installed.
Let's say this is /app/ .

I define a User Variable to capture this in my Test Plan:

name: appCxt    value: /app/

I can also install my web application to alternative contexts under the web 
server.

I define a User Variable to capture this in my Test Plan, and alter the above 
to do a second level expansion:

name: appCxt    value: ${stdAppCxt}

name: stdAppCxt value: /app/

Now, in general this seems to work. ${appCxt} ultimately expands to /app/ . I 
can define an HTTP Request with Path:

${appCxt}morepath/servletOneName

and when the Test Plan is run this expands to (all caps for generic terms 
instead of literal values):

http://IPADDR:PORT/app/morepath/servletOneName?PARAM=VALUE

Sidebar: I note that it is /app/morepath, not //app/morepath. This has minor 
interest when we get to the actual fault description below.

[[ In my actual Test Plan the only other thing worth mentioning is that VALUE 
is randomly selected from values in the preceding response. This is done using 
HTML Link Parser, and PARAM value of .* in the HTTP Request itself. I do not 
think this has bearing on the bug report. ]]

However things can get a bit more complex. Let's say I use __regexFunction to 
decide what part of the Path should be for my NEXT HTTP Request in my Test 
Plan. Path is like this:

${appCxt}${__regexFunction(ENCODED_ARGUMENTS)}

and when the Test Plan is run this expands to (all caps for generic terms 
instead of literal values):

http://IPADDR:PORT/${stdAppCxt}pathfromregexsubst/servletNameFromRegexGroupOne?
PARAM=VALUE

So, the INITIAL ${appCxt} has been expanded, and the ${__regexFunction()} has 
been executed and substituted, but the value of ${appCxt} has NOT been 
recursively expanded.

Is recursive expansions of ${} references in text fields intended in JMeter, or 
am I getting the recursive expansion in the simple case first stated by 
accident?  Is it recursive expansion or simply 2 passes at expansion?

This concludes the statement of the 'fault'.
What follows is incidental supporting information and the minor sidebar 
discussion.

[[ In my actual test plan the __regexFunction is something like this:
${__regexFunction(name%3D%22%5Cw%2BItemPage%22%5Cs%2Baction%3D%22%28%5Cw%
2BItemAction%29%22,SOMEPATH%2F%241%24,1,,OTHERPATH%2FSOMESERVLET,itemActionREF)}
which I think decodes to:
${__regexFunction(name="\w+ItemPage"\s+action="(\w+ItemAction)",SOMEPATH/$1
$,1,,OTHERPATH/SOMESERVLET,itemActionREF)} 

Also, the PARAM value for this HTTP Request with the Path problem is also found 
and substituted using another regex, similar in style to the Path fragment 
regex:
${__regexFunction(name%3D%22productId%22%5Cs%2Bvalue%3D%22%28%5Cw%2B%29%22,%241%
24,1,,NOMATCH,productIdREF)}
which I think decodes to:
${__regexFunction(name="productId"\s+value="(\w%+)",$1
$,1,,NOMATCH,productIdREF)} ]]

My workaround for the moment is to directly set appCxt to /app/, rather than 
${stdAppCxt}. This is the only way to not affect the body of my Test Plan and 
keep the workaround isolated to one easy to find place.

Sidebar: since it is /${stdAppCxt}pathfromregexsubst, I assume that in the 
simple case description above that /app/somepath occurs instead 
of //app/somepath due to smarts in JMeter for creating the URL from the various 
HTTP Request settings and fields. The leading '/' of Path value is dropped?

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