jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject JMeter: classpath vs NewDriver
Date Wed, 15 May 2019 18:15:44 GMT

When reviewing tests like org.apache.jmeter.testbeans.gui.PackageTest
and batchtest I identified an issue with current setup.

./bin/jmeter script puts just a single jar to the classpath which is
ApacheJMeter.jar (it uses java -jar ...).
Then NewDriver class figures out the location of lib, lib/ext and
builds its own classloader with account of the jars in those folders.

1) PackageTest is trying to search jars for the components, and it
uses ClassFinder to do that.
ClassFinder tries to check the value of java.class.path property to
filter jars here and there which is apparently wrong.

2) batchtest (both local and client-server) adds *all* jars to the
classpath when launching NewDriver. This differs from ./bin/jmeter way
of launching JMeter,
so I think "batch tests" should stick closer to the regular shell scripts.

This is something I've corrected in gradle branch otherwise
testbeans.gui.PackageTest failed to find classes to test.

PS. Frankly speaking, I find ClassFinder a quite fragile way of class
loading, however I suggest to postpone that refactoring (e.g.
DI-driven or classgraph/classgraph driven).
For now I just remove "java.class.path" filtering.


View raw message