Enable/disable components (like listeners) from CLI?

[David Luu <ma...@gmail.com>]

It's nice and easy to enable/disable components in GUI mode. Is there any
solutions for CLI mode?

I've so far used jmeter properties that I set in CLI, that are preset with
a default value into jmeter variables in test plan to handle this for CLI.
Unfortunately, this only works for components that have programmability
support to check such a flag before deciding to execute or not. Or you'd
have to combine the non-programmable (or not so programmable) components
with something that's programmable to control it (e.g. if controller).

How best to handle this for a listener component? I assume listeners are
generally top level under test plan (or in workbench), not generally nested
inside a thread group and then some controller? Or I guess the latter is ok
too?

I did add such a check (via jmeter property + variable combo defined in the
parameters list) in a custom BackEndListenerClient. Would be nice if the
default GraphiteBackEndListenerClient had similar capability. I'd rather
not have to modify that default client if I didn't have to. And having to
nest it under controllable components is less desirable.

Re: Enable/disable components (like listeners) from CLI?

[chaitanya bhatt <bh...@gmail.com>]

David,

Take a look at the Jmeter DSL developed by flood.io
https://github.com/flood-io/ruby-jmeter.

You can programmatically control the GUI options using the DSL. The only
problem I see with the DSL is you will have to develop your own DSL
extension if you want to control custom samplers.

Thanks
Chaitanya M Bhatt


On Thu, Jul 14, 2016 at 1:39 PM, David Luu <ma...@gmail.com> wrote:

> It's nice and easy to enable/disable components in GUI mode. Is there any
> solutions for CLI mode?
>
> I've so far used jmeter properties that I set in CLI, that are preset with
> a default value into jmeter variables in test plan to handle this for CLI.
> Unfortunately, this only works for components that have programmability
> support to check such a flag before deciding to execute or not. Or you'd
> have to combine the non-programmable (or not so programmable) components
> with something that's programmable to control it (e.g. if controller).
>
> How best to handle this for a listener component? I assume listeners are
> generally top level under test plan (or in workbench), not generally nested
> inside a thread group and then some controller? Or I guess the latter is ok
> too?
>
> I did add such a check (via jmeter property + variable combo defined in the
> parameters list) in a custom BackEndListenerClient. Would be nice if the
> default GraphiteBackEndListenerClient had similar capability. I'd rather
> not have to modify that default client if I didn't have to. And having to
> nest it under controllable components is less desirable.
>