You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Stephen Ash <st...@gmail.com> on 2012/08/03 01:01:05 UTC
Dynamically enable/disable HTTP Request Defaults parameters
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: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: Dynamically enable/disable HTTP Request Defaults parameters
Posted by Oliver Lloyd <ol...@hotmail.com>.
I'm pretty sure that Request Defaults is only evaluated once at compilation so it won't be dynamic but there are lots of ways to do what you want.
Could you send /foo?verboseLogs=false as a request? If so, that would make things very neat, you could just pass in the value for verboseLogs using -J. Also, what happens if you send /foo?verboseLogs=undefined? If this is acceptable (ie. it gets ignored) then this makes things even simpler.
If you really only want to specify this param when desired then you could use beanshell to build a var that is null when not required, so you'd have /foo${myParamVar} (I guess null values are acceptable, I'm not certain of this though).
And then, yes, you could have separate requests with conditional logic wrapped around them but, like you say, this is a bad solution as it creates duplication.
On 3 Aug 2012, at 00:01, Stephen Ash 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: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: Dynamically enable/disable HTTP Request Defaults parameters
Posted by Deepak Shetty <sh...@gmail.com>.
please use a different thread for a different issue
On Thu, Aug 2, 2012 at 8:07 PM, madhu sekhar <ma...@gmail.com>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 <sh...@gmail.com> 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 <st...@gmail.com>
> 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 <sh...@gmail.com>
> 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 <st...@gmail.com>
> > > 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: user-unsubscribe@jmeter.apache.org
> > > >> For additional commands, e-mail: user-help@jmeter.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > > For additional commands, e-mail: user-help@jmeter.apache.org
> > >
> > >
> >
>
>
>
> --
> madhu kk
>
Re: Dynamically enable/disable HTTP Request Defaults parameters
Posted by madhu sekhar <ma...@gmail.com>.
@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 <sh...@gmail.com> 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 <st...@gmail.com> 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 <sh...@gmail.com> 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 <st...@gmail.com>
> > 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: user-unsubscribe@jmeter.apache.org
> > >> For additional commands, e-mail: user-help@jmeter.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
> >
>
--
madhu kk
Re: Dynamically enable/disable HTTP Request Defaults parameters
Posted by Deepak Shetty <sh...@gmail.com>.
>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 <st...@gmail.com> 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 <sh...@gmail.com> 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 <st...@gmail.com>
> 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: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: Dynamically enable/disable HTTP Request Defaults parameters
Posted by Stephen Ash <st...@gmail.com>.
@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 <sh...@gmail.com> 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 <st...@gmail.com> 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: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: Dynamically enable/disable HTTP Request Defaults parameters
Posted by Deepak Shetty <sh...@gmail.com>.
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 <st...@gmail.com> 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: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>