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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
