I would consider such an implementation as a new "protocol" for JMeter. Currently JMeter supports HTTP pretty well, also supports JDBC and FTP less thoroughly. New "protocols" have recently been added, such as SOAP and arbitrary Java objects.
The value of being able to create Jython scripts that are then executed within the framework of JMeter is obvious - but it's not a replacement for the type of system I'm talking about. Not everyone who tests applications is a programmer. I'd like JMeter to be usable by such people. Furthermore, why would you want to write you're own regular expression routines and HTTP sampling routines if you didn't have to? If a Jython protocol were implemented, allowing people to write arbitrary Jython code to be "sampled", you'd have what you want, plus, you'd have access to some built-in JMeter values. -Mike On 10 Jul 2002 at 14:27, Ilia Iourovitski wrote: > Isn't it better to embed Jython into JMeter like MAXQ > does. > http://www.bitmechanic.com/projects/maxq/ > It will let users write real scripts. After all JMeter > about measurements. All tools like Silk Performer has > it. And it is much easier to debug jython script than > long set of tests. > > Ilia > > > --- "Stover, Michael" <[EMAIL PROTECTED]> > wrote: > > Recently I've noticed increased interest in making > > JMeter react more > > dynamically during test runs. This seems only > > natural. The HTML Link > > Parser provides some support, but really only seems > > to wet the appetite for > > more powerful options. > > > > So, I'm starting on a more general solution and > > thought some of you might > > want to give some input. > > > > I would like to allow users to embed simple > > reference elements as values in > > config and sampler objects, and then have a separate > > place where the value > > of these referenced elements would be specified. > > Currently, people use a > > Default Config Object to set universal values such > > as DOMAIN and PORT. I > > think a reference replacement system might be more > > intuitive than the > > current overlay system. Rather than leaving the > > DOMAIN field blank and > > supplying a Default Config in the correct place in > > the tree, one would > > instead insert a reference - such as ${my_domain} - > > which would be replaced > > when the test is compiled. Elsewhere, a table of > > all reference + > > replacement values would allow the user to change > > all such values in one > > location. > > > > This has many advantages over the current situation > > - it's generic, meaning > > one can use this system for any protocol. > > Currently, there is an HTTP > > Defaults, and FTP Defaults, etc. > > It allows all such elements to have one centralized > > home which should be > > easier to manage. > > > > For such user-defined values, this is simple. I've > > taken the variable style > > from Ant - ${var-name} - because I like it. Much > > preferable to XML IMO. A > > bit more explicit than a Perl style as well. > > Thoughts on this format would > > be much appreciated. Anything simpler than what > > I've come up with that does > > the job. > > > > Certain built-in values would be equally simple: > > ${__threadNumber} > > ${__threadName} > > ${__timestamp} > > ${__counter(0,100,1)} > > ${__xmlFile(c:\jmeter\bin\users.xml,username)} > > ${__literal[[${ant-variable}]]} > > > > Well, some are not so simple, but I'm hoping you get > > the idea. > > ${__threadNumber} is replaced by the current > > thread's number. I'm using > > "__" to indicate a built-in value as opposed to a > > user-defined variable > > name. > > > > ${__counter(0,100,1)} - for those familiar with the > > HTTP Parameter Mask, > > this might look familiar. The first number gives > > the starting point, then > > the end point, and the last is the increment. I > > think it's another way of > > getting the same effect. By embedding this variable > > into an argument name > > or value, you can get a similar effect: > > > > NAME PARAMETER > > username user${__counter(0,100,1)} > > > > This would create arguments in the following manner: > > username=user0 > > username=user1 > > username=user2 > > etc... > > > > Similarly, I see > > ${__xmlFile(c:\jmeter\bin\users.xml,username)} as a > > replacement for the User Parameter Modifier, though > > some complications have > > to be worked out. > > > > And ${__literal[[Anything at all]]} allows a user to > > use values that might > > otherwise conflict with this system. Although, that > > should be very rare, > > because variables not found in the table would be > > passed on as is. > > > > This is getting long, but I've implemented a more > > complex built-in variable > > that allows users to scrape values from responses > > using regular expressions. > > Right now, it takes the following form: > > > > > ${__responseVariable(REGULAR_EXPRESSION,prefix$1sometext$2suffix,[ALL|#|RAND > > |0.###],[between])} > > > > Take it slow. From the beginning, "__" indicates a > > built-in variable. > > "responseVariable" is the name used to find the > > correct Java class to > > execute. Then there are parentheses with arguments > > - just like the > > __counter(0,100,1) example above. There are 4 > > possible arguments, but only > > the first 2 are required (thus the square brackets > > showing optional args). > > > > The first argument is a regular expression, Perl > > style. This regular > > expression will be applied to the response data > > received from the previous > > request. > > > > The second argument provides a template for > > generating the string that will > > be substituted for this whole mess at run time. The > > variables ($1,$2) refer > > to regular expression groups (see Perl docs for more > > info). > > > > The next argument indicates which match, or matches, > > to use - if your > > regular expression finds more than one match in the > > data. ALL means use > > all. A number (starting from 1) indicates which > > value by it's order in the > > response. Thus, if you find 5 successful matches, a > > number of "3" means to > > use the third match. RAND means pick one at random. > > A float value is also > > a possible value. > > > > The fourth argument is a static string to go between > > matched values if ALL > > was chosen as the third argument value. > > > > Somewhat complex, though I envision a dialog > > allowing users to input these > > arguments in a friendly manner and then generating > > this string for them. > > > > -Mike > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
