Packaged Extensions

Apache JMeter 6.0.0 ships no plugin registry, no manifest to edit and no install command in the Apache download. Installing a third-party plugin means putting a JAR file in the right directory and restarting, so getting the directory wrong is the commonest reason a freshly downloaded plugin "does not appear". ## The three directories JMeter reads at startup `NewDriver`, the class `bin/jmeter` actually launches, builds JMeter's classloader before any other JMeter code runs. It looks in exactly three places under `JMETER_HOME`: - **`lib`** - utility and dependency JARs: JDBC drivers, messaging client libraries, and every library a plugin needs but does not bundle inside itself. - **`lib/ext`** - JMeter components and plugins: the JAR that contains samplers, listeners, timers, controllers, assertions, config elements and their GUI classes. - **`lib/junit`** - JARs holding the JUnit `TestCase` classes that the JUnit Request sampler drives. Every `.jar` found **directly** in those directories is added, sorted by name so the order is predictable across machines. Sub-directories are not walked, and anything that is not a `.jar` is skipped without comment - the manual notes that JMeter will only find `.jar` files, not `.zip`. ## Loadable is not the same as discoverable Because all three directories land on the classpath, a plugin JAR technically *loads* from any of them. What makes `lib/ext` special is discovery. `JMeterUtils.getSearchPaths()` returns `JMETER_HOME/lib/ext` first, followed by whatever the `search_paths` property adds, and that array is the search path JMeter's class finder walks when it builds the list of components it is able to offer. A component JAR dropped into `lib` sits on the classpath and can still be named explicitly, but nothing scans it, so its elements never appear in the tree's Add menus. The reverse mistake costs you as well. The manual says plainly that you should not use `lib/ext` for utility jars or dependency jars used by the plugins, because it is only intended for JMeter components and plugins. Piling a plugin's transitive dependencies into `lib/ext` turns every one of them into a candidate for the component scan on every startup: pure cost, no benefit. | Directory | What belongs there | On the classpath | Scanned for components | |---|---|---|---| | `lib` | utility and dependency JARs | yes | no | | `lib/ext` | plugin and component JARs | yes | yes | | `lib/junit` | JUnit `TestCase` JARs | yes | by the JUnit Request class chooser | ## The rules that trip people up 1. **`CLASSPATH` does nothing.** JMeter is started with `java -jar`, and the `java` command silently ignores both the `CLASSPATH` environment variable and the `-classpath`/`-cp` options when `-jar` is used. This is a Java rule, not a JMeter quirk, and the manual calls it out for exactly that reason. 2. **A restart is required.** The classloader is built and the component scan runs once, during startup. Copying a JAR into `lib/ext` while JMeter is open changes nothing until you relaunch it. 3. **Only `.jar`.** A directory of loose `.class` files, or a `.zip`, is invisible to the launcher. 4. **No recursion.** `lib/ext/mystuff/plugin.jar` is not found; `lib/ext/plugin.jar` is. 5. **A missing dependency reads like a broken plugin.** The plugin's element may appear in the menu, then fail with a `NoClassDefFoundError` the moment it runs, because its library never made it into `lib`. ## When you cannot write into the installation A locked-down or shared JMeter installation is common, and three properties in `bin/jmeter.properties` exist for it: `search_paths` adds directories to the component search path alongside `lib/ext`, while `user.classpath` and `plugin_dependency_paths` add directories of dependency JARs alongside `lib`. All three are shipped commented out, so none of them is set unless you set it. ## Why this outlives the first install An injector's `lib/ext` is part of a test plan's contract, not a local convenience. A `.jmx` records the fully qualified class name of every element it uses, so a plan authored on a workstation that has a plugin installed is unopenable on a machine that does not. Treat the contents of `lib` and `lib/ext` as something you provision deliberately - a container image layer, a checked-in directory, or a scripted install step - rather than something a person copies once and forgets.