skip to content

How would you govern the third-party JMeter plugins a team's test plans are allowed to depend on?

level: principalimportance: should knowfreq 38%

answer

  1. The plan is not where this belongs
  2. Pin something, and pin it in one place
  3. Ask what happens if upstream stops
  4. Some risk is not yours to carry

basics

~20 s

Treat the plugin set as part of the injector, not the plan: a pinned, reviewed list provisioned the same way everywhere. Decide per plugin whether it earns the coupling, and prefer JMeter's built-in hooks when it does not.

solid answer

~60 s

No single answer fits every team, but the decisions are the same. **Where the set lives:** one pinned inventory of plugin ids and versions, provisioned identically into every injector's `lib/ext`, not per laptop. **How it is installed:** baked into an image, vendored into the repository, or installed from the Plugins Manager's command line against an internal mirror - all three work, mixing them does not. **What earns a place:** a plugin buys a capability JMeter does not have; if a Java Request or a custom function would do, the built-in hook costs less over time. **What it costs:** every jar in `lib/ext` is opened and read class by class at startup - a `JMeter-Skip-Class-Scanning: true` manifest attribute spares it from that scan, but only in the lookups that combine the `ServiceLoader` with a scan, declaring `META-INF/services` alone spares it from nothing, and the GUI's menu scan reads every jar regardless - and every plugin binds to JMeter internals, so a JMeter upgrade can outrun it. **What you cede:** licence and supply-chain review of the jar belongs with your application-security practice, and is not optional.

go deeper

for a junior

Understand that plugins are installed per machine, so a plan that works for a colleague may not work for you until the same jars are present.

for a middle

Explain why a plugin has to be pinned and provisioned rather than downloaded ad hoc, and what the plan file does and does not record about it.

for a senior

Run the provisioning: one mechanism, pinned versions, verified before the run, with a plan for the day a plugin no longer matches the JMeter release.

for a principal

Own the inventory and the entry rule - what a plugin must earn, who reviews it, what happens when upstream stops - and route licence and supply-chain risk to the function that owns it.

Third-party plugins are how most JMeter installations stop being the Apache download. That is often the right call - the ecosystem fills real gaps - but a plugin set that grew by accident becomes the reason a plan will not open, a build will not reproduce, and an upgrade cannot be scheduled. Governing it is a small amount of deliberate work with a long payoff. ## Decide what a plugin has to earn JMeter has three built-in hooks for behaviour it does not ship: the Java Request sampler driving a `JavaSamplerClient`, the JUnit Request sampler driving existing `TestCase` classes, and a custom function implementing `Function`. Each of these is code you own, in a jar you build, with no upstream to track. A third-party plugin is worth the coupling when it supplies something those hooks cannot reasonably reproduce - a protocol implementation, a whole element family, a mature piece of behaviour with users. It is not worth it when a twenty-line `JavaSamplerClient` would do. The honest question at review time is: *if this plugin stops being maintained, what do we do?* If the answer is "write the Java Request we should have written", write it now. ## Fix the inventory, then fix the provisioning Write down the plugin ids and exact versions the team is allowed to use, and make one mechanism put them in place: 1. **Image layer** - jars copied into `lib/ext` and `lib` at build time. Strongest reproducibility; the image tag *is* the plugin set. Needs an image build to change anything. 2. **Vendored directory** - jars in the repository beside the plans, with `search_paths` and `plugin_dependency_paths` pointing at the checkout. The plan and its plugins move together; the cost is binaries in git. 3. **Install step** - the third-party Plugins Manager's command line (`PluginsManagerCMD`) resolving pinned ids such as `jpgc-dummy=0.4` before the run. Most flexible, and the only one that needs a repository reachable at job time; its `jpgc.repo.address` property takes a semicolon-separated list, so an internal mirror can be placed first, and on an id conflict the earliest declared repository wins. All three are defensible. What is not defensible is two of them at once, where nobody can say which jar actually ran. ## The recurring costs to budget for - **Startup scanning.** JMeter's class finder walks the jars on the component search path to build its element lists. A jar that declares its plugins through `META-INF/services` and carries `JMeter-Skip-Class-Scanning: true` can be skipped; one that does not is loaded class by class. A large `lib/ext` is a slower JMeter for everyone. - **Upgrade coupling.** Plugins bind to JMeter internals, and the Plugins Manager's catalogue will not warn you: a version entry carries only `downloadUrl`, `changes`, `libs` and `depends`, and the sole version constraint it can express is a minimum for a *dependency library* (`"cmdrunner>=2.3"`). Where a minimum JMeter version is recorded at all it is prose inside a `changes` or `description` blurb. Tracking plugin-to-JMeter compatibility is therefore work you own: upgrade JMeter and the plugin set together, keep the previous image tag until a real run has passed on the new one, and expect the least-maintained plugin to be the thing that pins your JMeter version. - **Reviewability.** A plan whose elements come from five vendors is harder for a newcomer to read, and the jp@gc labelling convention that prefixes plugin elements in the menus is the only visible clue about where an element came from. - **Telemetry and network posture.** The Plugins Manager reports anonymous usage to its home site by default and exposes `jpgc.repo.sendstats=false` to turn that off; whether that is acceptable is an organisational decision, not a testing one. ## What you should not own here Licence compatibility and supply-chain risk for a downloaded jar are real and they are not the load-testing team's speciality. Name them explicitly, route them to whoever runs your application-security and dependency review, and make the plugin inventory the artefact they review. Similarly, the mechanics of resolving and caching artefacts belong to your build and repository tooling; the point here is only that a JMeter plugin does not arrive through them by default, because JMeter reads directories rather than a dependency graph. ## A workable steady state - One written inventory: id, version, why it is there, who reviewed it. - One provisioning mechanism, used by CI and by workstations alike, so "works on my machine" stops being possible. - A rule that a new plugin needs a named owner and a fallback plan. - A scheduled review that removes what nothing uses - the cheapest plugin is the one you deleted.

  • When would you tell a team to write a Java Request instead of installing a plugin?
    When the behaviour is small, specific to your systems, and reproducible in a class you own - a signing routine, an internal SDK call, a bespoke workload driver. You trade an upstream you cannot control for a build step you can, and the fallback plan question answers itself because the code is already yours.
  • How do you keep a JMeter upgrade from being blocked by the plugin set?
    Track the minimum-JMeter requirement of every plugin you install, upgrade JMeter and the plugin set as one change, and hold the previous injector image until a real run passes on the new one. Where a plugin has no compatible release, decide early whether to replace it with a built-in hook or defer the upgrade deliberately.
  • What belongs to application security rather than to the testing team here?
    Licence compatibility and supply-chain review of the downloaded jars. The testing team's job is to produce a pinned, written inventory of plugin ids and versions and to keep it accurate; deciding whether a given artefact and its transitive libraries are acceptable to ship is the security and dependency-review function's call.

saying these in an interview costs you the question

  • Lets each engineer install plugins on their own machine
  • Installs the newest available plugin version on every run
  • Treats licence and supply-chain review as somebody else's problem entirely
  • Adds a plugin without asking what replaces it if it dies
  • Upgrades JMeter without checking the plugin set first