DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27480>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27480 Can't use CSVRead in HTTP Request Defaults - problem with 'next' actually [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2004-03-09 21:01 ------- Thanks for the test case - the problem proved to be quite interesting! Turns out that the fields on the HTTP Request Defaults Screen are not processed in the order one might expect. As it happens, the Server Name is processed before the Port. You can see this by adding different ${__logn(SomeText)} calls to the end of the lines. The __logn() function logs the text, and returns the empty string. [The similar __log() function logs the text but returns its first parameter, so can be used as follows: ${__log(${__somefunc()})}] In my test, using logn() shows the following sequence: Path, Server, Protocol, Port, Protocol, Port, Server, Path, Server, Protocol, Port, Protocol, Port, Server. No wonder next does not seem to work! There is no guarantee as to the order in which Sampler fields will be evaluated and the order may change from release to release or even between releases. The standard way to use CSVRead (and StringFromFile etc) is to use them to set up variables in a User Parameters Pre-Processor element, and then reference the variables from then on. Functions which always return the same value (e.g. __machineName()) can of course be used safely in Samplers. Changing the status to Fixed - hope that's OK; if not, please reopen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
