please use a different thread for a different issue On Thu, Aug 2, 2012 at 8:07 PM, madhu sekhar <[email protected]>wrote:
> @Deepak, Can you please explain how to use beanshell preprocessor to > capture values from java script? > > On Fri, Aug 3, 2012 at 8:27 AM, Deepak Shetty <[email protected]> wrote: > > > >I would rather not have to duplicate the pre-processors over and over > > again. > > If you create the pre processor under the thread group then it applies to > > all samplers (just like the defaults element) > > > > On Thu, Aug 2, 2012 at 6:55 PM, Stephen Ash <[email protected]> > wrote: > > > > > @Deepak > > > Thanks for the suggestion. I tried it out, and that method did work. > > > Since there can be many samplers in the test, I would rather not have > > > to duplicate the pre-processors over and over again. Hence wanting to > > > get it working in the Defaults element. > > > > > > @Oliver > > > That is a clever way of handling it. I hadn't thought of constructing > > > the whole optional part of the query string. Yes, the parameters can > > > be more than just Boolean values (probably a bad example), so I worked > > > off your suggestion and got things working. What I ended up doing is > > > kinda strange, and looks ugly, bug it keeps all the optional > > > parameters in one place. > > > > > > Inside the Test Plan element, I set up a variable > > > optionalParameters=${__P(optionalParameters, false)} and also a > > > variable that was verboseLogs=${__P(verboseLogs, true)}. Inside my > > > HTTP Request Defaults was where the cool stuff happens. I added a > > > parameter with the name being ${__BeanShell( if ( > > > vars.get("optionalParameters").toString().equalsIgnoreCase("true") ) > > > return "verboseLogs"; )} and the value being ${__BeanShell( if ( > > > vars.get("optionalParameters").toString().equalsIgnoreCase("true") ) > > > return vars.get("verboseLogs"); )}. Basically if > > > optionalParameters=true, then make a parameter > > > verboseLogs=${verboseLogs}. Otherwise, both sides will be an empty > > > string and JMeter will ignore it. > > > > > > What I like about keeping that in the HTTP Request Defaults is that I > > > can leverage the encode logic from JMeter (instead of recreating it > > > outside and passing it into the script). I also get to use these > > > optional variables in multipart/form POST requests without any other > > > changes. It seems excessive to have to check the ${optionalParameters} > > > value over and over, but I guess it works, so I should be happy! > > > > > > Thanks! > > > > > > On Thu, Aug 2, 2012 at 4:28 PM, Deepak Shetty <[email protected]> > wrote: > > > > Hi > > > >>Is there a way to modify that test element dynamically during the > test > > > > execution? > > > > A beanShell preprocessor can access the HTTPSampler - and should be > > able > > > to > > > > remove arguments on the fly (but I havent tested it) - and how you > > > identify > > > > what it is to be removed is upto you > > > > Alternately don't use request defaults and use the preprocessor to > add > > > > arguments dynamically (and how you determine what to add is your > code) > > > .e.g > > > > > > > > > > http://theworkaholic.blogspot.com/2010/03/dynamic-parameters-in-jmeter.html > > > > > > > > regards > > > > deepak > > > > > > > > On Thu, Aug 2, 2012 at 4:01 PM, Stephen Ash <[email protected]> > > > wrote: > > > > > > > >> In the following test plan example, the HTTP Request Defaults > element > > > >> is applied to all HTTP Samplers. Is there a way to modify that test > > > >> element dynamically during the test execution? > > > >> > > > >> The use case is that each of the /foo, /bar, /baz requests can take > an > > > >> optional request parameter. So both GET /foo and GET > > > >> /foo?verboseLogs=true would be valid requests. I was looking for a > way > > > >> to pass in a property (-JoptionalParameters=true) to JMeter in order > > > >> turn on or off those arguments. > > > >> > > > >> Test Plan > > > >> - HTTP Request Defaults > > > >> - Thread Group > > > >> -- HTTP Sampler (GET /foo) > > > >> -- HTTP Sampler (GET /bar) > > > >> -- HTTP Sampler (GET /baz) > > > >> > > > >> A couple of things that I have tried so far without luck: > > > >> - Move the HTTP Request Defaults into the Thread Group and then > > > >> surround with an If Controller. This causes the HTTP Requests > Defaults > > > >> to only be in the context of the If Controller now, and not > propagated > > > >> up the If Controller's parent. > > > >> - Adding a BeanShell pre-processor to the Test Plan or Thread Group > > > >> that will get the ThreadGroup from the current context and add a new > > > >> Debug Sampler Element (would swap with ConfigTestElement later). > That > > > >> probably won't work in general since the structure of the test is > > > >> already defined and not re-evaluated when I add the Test Element. > > > >> > > > >> Some things that will work, but I would like to avoid since they are > > > >> not as sustainable: > > > >> - Split into two separate scripts/thread groups, one with and one > > > >> without the optional parameters. > > > >> - Pass in another JMeter property for the parameter's key. The HTTP > > > >> Requests Default would have an argument where name=${verboseKey} and > > > >> value=${verboseValue}. If I wanted the parameter, I would have to > set > > > >> verboseKey="verboseLogs=" and verboseValue="true". This becomes hard > > > >> to manage with many parameters. > > > >> > > > >> Any other ideas to try would be appreciated. > > > >> > > > >> Thanks. > > > >> > > > >> > --------------------------------------------------------------------- > > > >> 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] > > > > > > > > > > > > -- > madhu kk >
