About bsh.shared:
http://jmeter.apache.org/usermanual/best-practices.html#bsh_variables
This is namespace which is available to all threads. You can store any variable
(or reference) in bsh.shared from any thread and get it from any thread. In
other languages (e.g. JSR223+groovy) you can achieve the same behavior by
implementing your own singleton-like class to store shared state.
One more option described at the link given (via JMeterUtils), but it's only
available for strings.
Another possible option is to use props (props.put()/props.get()). Keep in mind
that props keep their values between test runs, you may want it or not.
Whatever way you choose, keep in mind that you have to take care about thread
synchronization when reading and modifying stored variable, otherwise you can
get unpredictable results. Convenient way to achieve this implicitly is to use
Java Concurrency classes.
You may store your values in JMeter variables to access them easily from
samplers (like that: ${my_var}). But vars should be initialized in every thread
because variable is available only in those thread which has initialized it.
This can be done in BeanShell also.
If you decide to use properties, you will be able to access properties from
fields of various samplers using function: ${__property(my_prop)}.
-----
VR
-----Original Message-----
From: Sam Drew [mailto:[email protected]]
Sent: Tuesday, July 01, 2014 7:18 PM
To: JMeter Users List
Subject: Re: Custom Configuration Plugin
Thanks,
It looks like that should be possible. I didn't realise that BeanShell was able
to run arbitrary Java classes.
How would I go about putting the Map<String,String> properties into bsh.shared
so that other test elements can make use of them? Would iterating through the
key set and doing vars.put(key, value); allow me to access them in
threads/samplers?
Regards,
Sam.
On 1 Jul 2014, at 11:24, Ryabtsev Vladimir <[email protected]> wrote:
> You plan to use this configuration step just once during the test run, right?
> Why don't you use BeanShell Sampler in SetUp Thread Group with bsh.shared or
> something similar?
>
> -----
> VR
>
>
> -----Original Message-----
> From: Sam Drew [mailto:[email protected]]
> Sent: Tuesday, July 01, 2014 11:22 AM
> To: [email protected]
> Subject: Custom Configuration Plugin
>
> I'm trying to write a custom JMeter module, that will run a Java method that
> I use for Server Setup and returns Map<String,String> as configuration
> properties that can be used in sampling.
>
> At the moment I am slightly unsure of what TestElement I should be extending
> or implementing in order to achieve this, given that it seems to sit
> somewhere between a PreProcessor and ConfigTestElement, in that it is both
> setting up pre-conditions for the test and then providing these as
> configuration parameters.
>
> After looking at the example in jmeter-plugins for csv config element I wrote
> a class which was little more than
>
> class CreateMyServerConfig extends Arguments {
> @Override
> public Map<String, String> getArgumentsAsMap() {
> return ServerInstance.getServerInstance().getPropertiesAsMap();
> }
> }
>
> Where getServerInstance would first generate a VM Instance and later just
> provide a reference to the one created. When I tried to run a test plan with
> it in the code never appeared to be executed, and I never really knew what to
> expect. And whether/when this code might be called (particularly as I only
> really want it run once).
>
> I was hoping that someone might be able to tell me which path to follow,
> whether I'm barking up the wrong tree and which resources might be helpful. I
> have looked at https://jmeter.apache.org/extending/jmeter_tutorial.pdf, have
> seen various information relating to building custom samplers, and have even
> used the Java Request Sampler in the past, however this has me completely
> stumped.
>
> Alternatively a way to deal with JMeter's configuration such that I could
> embed JMeter in a jar and load the config from classpath would allow me to
> run the code manually before starting JMeter from within Java.
>
> Thanks,
>
> Sam.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
