Solution for plugins

[AntonioSun]

Collecting general ideas for proper solutions for plugins.

plugins are challenging as there are so many out there and it is nearly impossible to support every one of them. For e.g., I need to used this one:

https://docs.datadoghq.com/integrations/jmeter

which nobody else might be using, including the author.

So we need a generic way for people to use plugins on their own.

One idea come to my mind is that, since groovy-jmeter supports including jmeter fragments directly. Can we use such mechanism to use plugins on our own? A working example appreciated. thx.

Update:

The above is Datadog Backend Listener plugin, which will represent one single block of xml in the jmeter file, which should be doable.

Now the real challenge is, I want to use this as well:

https://jmeter-plugins.org/wiki/InterThreadCommunication/

It can be applicable to every request. So maybe, instead of groovy-jmeter doing the translation for every single plugins, would something like insert-raw that insert raw jmeter xml code block be a generic way / solutioin?

If so, it can be the solution for #73 as well, as I need the insert mechanism be granular enough so as to be able to add different jmeter code block (from different files) all into a single variable definition.

With that (insert-raw or anything alike), the workflow would be

• generate jmeter xml code from groovy-jmeter script
• add the desired plugin or whatever not supported by groovy-jmeter out of the box by now
• find the diffs between them and copy the added blocks into (different) files
• apply insert-raw to groovy-jmeter script at where the new codes should be added
• redo the jmeter xml code generation by groovy-jmeter

Some parameters might need to be passed to the insert-raw, but it should be doable.

[smicyk]

Hi, this is one of the next items which I'm going to do but to be honest the plugins are already supported. The mechanism is working and it is used unit tests. The way it is done right now is only used there and was created for that purpose only so it is kind of secret feature :).

Nevertheless, you can create the plugin if you follow what is done in the tests:

1. First create your custom jmeter test element

class LogSampler extends AbstractSampler {

    SampleResult sample(Entry e) {
       SampleResult res = new SampleResult()

        res.sampleLabel = name // element name property
        res.sampleStart()
        res.dataType = SampleResult.TEXT
        res.samplerData = comment // element comment property
        res.setResponseOK()
        res.sampleEnd()

        return res
    }
}

The you need the LogSamplerFactory to glue the plugin with groovy-jmeter

final class LogSamplerFactory extends TestElementNodeFactory {
    
    // Log Sampler name, the default one
    LogSamplerFactory(String testElementName) {
        super(testElementName, LogSampler, TestBeanGUI, true, keyword('log', KeywordCategory.SAMPLER))
    }
}

In your script you use it in the following way:

start(plugins: [new LogSamplerFactory('Log Sampler)]) {
    plan {
        group {
            log(name: 'custom name', comments: 'custom comments')
        }
    }
}

Both name and comments will be initialized on the SampleResult.

So it can be done right now but there so cavities:

• there is no restriction about the keyword you will use so you can override existing one, can lead to lots of strange problems
• there is no namespace or similar stuff so you can create similar implementation of already existing stuff or maybe you want to use the same name for something already exists (and different plugins can have similar stuff)
• adding new plugin to the script is cumbersome in my opinion it should be something similar how it is done in gradle with own keyword
• it might be not possible to add the keyword on all levels of the script e.g. jdbc keyword is separated from the default one so it will work in all places except jdbc

The alternative insert-raw. This actually is already in place I think with include keyword.

So, the include just includes JMX file to your script.

strart {
    plan {
         include '/path/to/my.jmx'
    }
}

So any valid jmx can be included and it should work. The only thing you need to remember is to add plugin jars to the classpath. Depending how you write your script you can do it with Grab or in gradle.

[AntonioSun]

The way it is done right now is only used there and was created for that purpose only so it is kind of secret feature :).

Thanks, that's good news and I'd like to try that. However, I don't have the knowledge to put them together.

Would you put out a fully working example instead please?

For an example that could benefit most people, would you provide the example for the Dummy Sampler please (using Dummy Sampler together with normal working groovy-jmeter script that is)? It is not integrated into JMeter by default, but it’s part of JMeter Plugins and it is a powerful sampler -- it can generate fake results with any of content you want..

TIA

[AntonioSun]

The alternative insert-raw. This actually is already in place I think with include keyword.

I tried this include alternative as per your suggestion and find it is not what I was asking for. So, let me explain with an concrete example, using the same code from #57 (comment)

The

    variables {
      variable(name: 'c_lt_users', value: '${__P(c_lt_users, 10)}', description: 'loadtest users')
      variable(name: 'c_lt_ramp', value: '${__P(c_lt_ramp, 5)}', description: 'loadtest ramp up in seconds')
      }

part within plan will generate the following .jmx code:

    <hashTree>
      <Arguments guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments">
          <elementProp name="c_lt_users" elementType="Argument">
            <stringProp name="Argument.name">c_lt_users</stringProp>
            <stringProp name="Argument.value">${__P(c_lt_users, 10)}</stringProp>
            <stringProp name="Argument.metadata">=</stringProp>
            <stringProp name="Argument.desc">loadtest users</stringProp>
          </elementProp>
          <elementProp name="c_lt_ramp" elementType="Argument">
            <stringProp name="Argument.name">c_lt_ramp</stringProp>
            <stringProp name="Argument.value">${__P(c_lt_ramp, 5)}</stringProp>
            <stringProp name="Argument.metadata">=</stringProp>
            <stringProp name="Argument.desc">loadtest ramp up in seconds</stringProp>
          </elementProp>
        </collectionProp>
      </Arguments>
      <hashTree/>

If so, it can be the solution for #73 as well, as I need the insert mechanism be granular enough so as to be able to add different jmeter code block (from different files) all into a single variable definition.

By above I meant that I'm able to construct the above xml block myself from raw xml pieces. I.e., the following will give me the exact same code as above:

    variables {
      // variable(name: 'c_lt_users', value: '${__P(c_lt_users, 10)}', description: 'loadtest users')
      // variable(name: 'c_lt_ramp', value: '${__P(c_lt_ramp, 5)}', description: 'loadtest ramp up in seconds')
      insert-raw 'example-inc.v1.jmx'
      insert-raw 'example-inc.v2.jmx'
      }

If the example-inc.v?.jmx files are like the following:

$ head example-inc.v?.jmx
==> example-inc.v1.jmx <==
          <elementProp name="c_lt_users" elementType="Argument">
            <stringProp name="Argument.name">c_lt_users</stringProp>
            <stringProp name="Argument.value">${__P(c_lt_users, 10)}</stringProp>
            <stringProp name="Argument.metadata">=</stringProp>
            <stringProp name="Argument.desc">loadtest users</stringProp>
          </elementProp>

==> example-inc.v2.jmx <==
          <elementProp name="c_lt_ramp" elementType="Argument">
            <stringProp name="Argument.name">c_lt_ramp</stringProp>
            <stringProp name="Argument.value">${__P(c_lt_ramp, 5)}</stringProp>
            <stringProp name="Argument.metadata">=</stringProp>
            <stringProp name="Argument.desc">loadtest ramp up in seconds</stringProp>
          </elementProp>

However, the

    variables {
      // variable(name: 'c_lt_users', value: '${__P(c_lt_users, 10)}', description: 'loadtest users')
      // variable(name: 'c_lt_ramp', value: '${__P(c_lt_ramp, 5)}', description: 'loadtest ramp up in seconds')
      include 'example-inc.v1.jmx'
      include 'example-inc.v2.jmx'
      }

Will give a completely different xml:

    <hashTree>
      <Arguments guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
      </Arguments>
      <hashTree>
        <IncludeController guiclass="IncludeControllerGui" testclass="IncludeController" testname="example-inc.v1.jmx" enabled="true">
          <stringProp name="IncludeController.includepath">example-inc.v1.jmx</stringProp>
        </IncludeController>
        <hashTree/>
        <IncludeController guiclass="IncludeControllerGui" testclass="IncludeController" testname="example-inc.v2.jmx" enabled="true">
          <stringProp name="IncludeController.includepath">example-inc.v2.jmx</stringProp>
        </IncludeController>
        <hashTree/>
      </hashTree>

[AntonioSun]

Hi @smicyk, hope that you've been considering this insert-raw xml idea, as I badly need a generic way to add unsupported code on my own now.
or a fully working example for unsupported plugin can also help for now.

thx.

[AntonioSun]

The alternative insert-raw. This actually is already in place I think with include keyword.

Hmm... that'll work for controllers but not plugins right? I currently need to add plugins, like the datadog plugin in OP.

[AntonioSun]

that'll work for controllers but not plugins right? I currently need to add plugins, like the datadog plugin in OP.

I meant,

The Include Controller can only be used within Thread Group:

But for Datadog Backend Listener and all other plugins, they are all directly under Test Plan, and can not be included with the Include Controller, right?

[smicyk]

Hi, yeah, it seems that works only in groups.

[AntonioSun]

😭😭😭
hope that you've been considering this insert-raw xml idea then, as I badly need a generic way to add unsupported code on my own now.
thx!

[smicyk]

Hi, with #104 there is plugin support. In the plugins examples you can see how to build whole project which use plugin dummy example.

Regarding the datadog plugin it actually turns out you can use it right now without much fuss. The example is in plugins examples datadog. The datadog plugin use the backend listener which needs to be properly configured in the script. Sorry I didn't notice it before.

[AntonioSun]

🎉🎉🎉🎉🎉🎉

[AntonioSun]

I took a look at #104 which has plugin support before raising #112, because I was trying to follow it and solve the problem myself, but found that the learning curve is way too steep for me, as I'm not a Java programmer, let alone a Groovy DSL programmer. So I want to bring attention back to this proposal again:

Collecting general ideas for proper solutions for plugins.

... So maybe, instead of groovy-jmeter doing the translation for every single plugins, would something like insert-raw that insert raw jmeter xml code block be a generic way / solutioin?

With it, the solution would be super simple, even to a none Java programmer, as he only need to put the missing code block from jmx in, something like

insert_raw ```
      <BackendListener guiclass="BackendListenerGui" testclass="BackendListener" testname="Backend Listener" enabled="true">
        <elementProp name="arguments" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" enabled="true">
          <collectionProp name="Arguments.arguments">
            <elementProp name="testName" elementType="Argument">
              <stringProp name="Argument.name">testName</stringProp>
              <stringProp name="Argument.value">${c_cfg_TestName}</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="nodeName" elementType="Argument">
              <stringProp name="Argument.name">nodeName</stringProp>
              <stringProp name="Argument.value">${TestDesc}</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="runId" elementType="Argument">
              <stringProp name="Argument.name">runId</stringProp>
              <stringProp name="Argument.value">${runId}</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="influxDBHost" elementType="Argument">
              <stringProp name="Argument.name">influxDBHost</stringProp>
              <stringProp name="Argument.value">xyz</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="influxDBPort" elementType="Argument">
              <stringProp name="Argument.name">influxDBPort</stringProp>
              <stringProp name="Argument.value">8086</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="influxDBUser" elementType="Argument">
              <stringProp name="Argument.name">influxDBUser</stringProp>
              <stringProp name="Argument.value">jmeter</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="influxDBPassword" elementType="Argument">
              <stringProp name="Argument.name">influxDBPassword</stringProp>
              <stringProp name="Argument.value">PW</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="influxDBDatabase" elementType="Argument">
              <stringProp name="Argument.name">influxDBDatabase</stringProp>
              <stringProp name="Argument.value">jmeter</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="retentionPolicy" elementType="Argument">
              <stringProp name="Argument.name">retentionPolicy</stringProp>
              <stringProp name="Argument.value">autogen</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="samplersList" elementType="Argument">
              <stringProp name="Argument.name">samplersList</stringProp>
              <stringProp name="Argument.value">Upload.*</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="useRegexForSamplerList" elementType="Argument">
              <stringProp name="Argument.name">useRegexForSamplerList</stringProp>
              <stringProp name="Argument.value">true</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
            <elementProp name="recordSubSamples" elementType="Argument">
              <stringProp name="Argument.name">recordSubSamples</stringProp>
              <stringProp name="Argument.name">recordSubSamples</stringProp>
              <stringProp name="Argument.value">true</stringProp>
              <stringProp name="Argument.metadata">=</stringProp>
            </elementProp>
          </collectionProp>
        </elementProp>
        <stringProp name="classname">rocks.nt.apm.jmeter.JMeterInfluxDBBackendListenerClient</stringProp>
      </BackendListener>```

And that's it!

No need to learn Java programming; no need to learn Groovy DSL programming, and no need to bother you the author for every single exotic plugin on earth. It's less ideal, and not elegant at all, but because of no need to wait for the next version with perfect fix, everyone would be happy...

[smicyk]

Hi, I will think about it but right now it doesn't seem to be very easy to implement.

[AntonioSun]

Oh, no wonder.
I was only trying to propose some easy solutions, as I was thinking putting some lines as-is in the output would be easy.
Alright then, no need to get yourself into trouble, the goal here is to make both you and the users' life easier. But please do keep this requirement in mind, and hope one day you can come up with something that satisfies both sides.

[smicyk]

Hi, #116 add the include_raw keyword. You can add the any test element with it but you can't add part of the jmx only the whole jmx related to test element e.g. BackendListener as you make it in #86 (comment)

[suntong]

🎉🎉🎉