Created attachment 30783 [details] Implementation plus docs JMeter currently has three configurations to tune class loading: - property search_paths: should be used for plugins but not for their dependency libs. All jars must be listed explicitely. Separator is ";". JMeter uses the items given to search for implementations of specific interfaces. - property user.classpath: should be used for utilities and plugin dependencies. All jars must be listed explicitely. Separator is platform path separator (e.g. ":", ";", ...). The items listed are added to the system class path and also to the class path of the JMeter class loader. - user defined class path in JMeter test plan: should be used for utilities and plugin dependencies. All jars must be listed explicitely. The items listed are only added to the class path of the JMeter class loader. If a JMeter plugin has lots of dependencies (in my case about 100 Jar files with a total size of about 100 MB), then one can only add them either to user.classpath and they end up in the system class path as well - unneeded. Or one adds them to the test plan. In both cases there is no way to let JMeter simply use all jars sitting in a configured directory. The attached patch adds a property "plugin_dependency_paths" which allows to set a user defined class path with the same semantics as the test plan one outside as a property. Items are only added to the class path of the JMeter loader, not the system class path. Separator is ";". The patch also adds the functionality to all three properties, "search_paths", "user.classpath" and "plugin_dependency_paths", that if one of the items is a directory, all jar files contained in that directory are also added to the list. I also adjusted the documentation for the existing and the new property. Regards, Rainer
Thanks very much; looks very useful. In the case of a directory, the code only includes jar files in the directory, and does not descend the directory tree. This could perhaps be made clearer in the documentation. Some minor nits: The code: if (furl.exists() && furl.isDirectory()) could surely be replaced with this? if (furl.isDirectory()) changes.xml says: "now automatically add all jars form configured directories" s/form/from/ Also the directory scanning code is repeated; it could be extracted as a method. And perhaps it should check if the jar file is readable?
Created attachment 30784 [details] Updated patch (In reply to Sebb from comment #1) > In the case of a directory, the code only includes jar files in the > directory, and does not descend the directory tree. This could perhaps be > made clearer in the documentation. Tried to rephrase more clearly. > Some minor nits: > > The code: > if (furl.exists() && furl.isDirectory()) could surely be replaced with this? > if (furl.isDirectory()) Done > changes.xml says: > "now automatically add all jars form configured directories" > s/form/from/ Corrected > Also the directory scanning code is repeated; it could be extracted as a > method. Done. > And perhaps it should check if the jar file is readable? Done.
OK, looks good to me
URL: http://svn.apache.org/r1518769 Log: Improve class loading: - New property "plugin_dependency_paths" for plugin dependency jars. Paths get added to JMeter loader but not the system class path. - Jar files contained in a directory configured in one of the properties "search_paths", "user.classpath" or "plugin_dependency_paths" are automatically added to the same property as well. This is not true for jar files contained in sub directories. Bugzilla Id: 55503 Modified: jmeter/trunk/bin/jmeter.properties jmeter/trunk/bin/user.properties jmeter/trunk/src/core/org/apache/jmeter/JMeter.java jmeter/trunk/src/core/org/apache/jmeter/NewDriver.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml jmeter/trunk/xdocs/usermanual/get-started.xml
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3215