jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: user.classpath, search_path and many jar files
Date Mon, 12 Aug 2013 12:13:35 GMT
On 11.08.2013 23:40, Rainer Jung wrote:
> On 11.08.2013 21:45, Philippe Mouawad wrote:
>> On Fri, Aug 9, 2013 at 9:45 PM, Rainer Jung <rainer.jung@kippdata.de> wrote:
>>
>>> I have a situation where the user.classpath contains many jar files
>>> (about 100). Listing all of the jar files is tedious, difficult to
>>> maintain and not in any place where one can configure user.classpath
>>> possible or easy because of line length restrictions.
>>>
>>> Looking at the code I saw that in some places jar files lying in
>>> directories configured for class search are automatically also searched,
>>> but sometimes not.
>>>
>>> There are three cases:
>>>
>>> - not auto-searching the jar files:
>>>
>>> o.a.jmeter.JMeter start() calls updateClassLoader() calls updatePath()
>>> for search_paths and user.classpath. updatePath() calls
>>> NewDriver.addPath() for each path contained in those settings. Finally
>>> NewDriver.addPath() adds them to the system property "java.class.path"
>>> without listing all jar files contained in directories.
>>>
>>> So the class loader itself does not know about such jar files.
>>>
>>> - auto-searching such jar files in ClassFinder.findClassesThatExtend()
>>> using search_paths for JMeter extension:
>>>
>>> In findClassesThatExtend() a call to addJarsInPath() will automatically
>>> add all jar files found in a configured directory.
>>>
>>> - auto-searching jar files in user.classpath for JUnit setup:
>>>
>>> In JUnitTestSamplerGui the user.classpath property is used to search for
>>> classes extending Test or TestCase but the search is based on
>>> ClassFinder, so will automatically search through jar files.
>>>
>>> I propose to also add the jar files in the first case, the updatePath
>>> setting up the class loader. I guess the only concern would be the speed
>>> of class loading? IMHO if there are only few such jar files, then there
>>> should be no problem and if there are many such jar files, then not
>>> needing to configure them all is really helpful. So the remaining case
>>> is if there are many jar files auto-detected which are not really
>>> needed. That means it might make sense to make the behavior configurable
>>> with default the old behavior.
>>>
>>> Comments?
>>>
>> Not clear for me. Could you illustrate with an example ? thanks
> 
> Not really tested, but you might get the idea:
> 
> http://people.apache.org/~rjung/patches/jmeter-user_classpath-load_jars.patch
> 
> The added code is similar to the handling of jars in the method
> addJarsInPath() called from findClassesThatExtend() of class ClassFinder.
> 
> Example is a jmeter extension (here a java sampler) that has lots of
> dependencies. All of those (about 100) jars would need to be added to
> user.classpath.
> 
> If we agree to include all jars located in some path component of
> user.classpath automatically, then one could simply put the 100 jar
> files in some directory, e.g. /my/sample/dependencies, and set
> 
> user.classpath=/my/sample/dependencies
> 
> For search_paths this already works, but not for user.classpath.

Sorry my patch was rubbish. There are two types of user.classpath. I
changed the impl for the user.classpath given in the properties file.
But the entries there are also added to the system classpath, so you
don't want your extension dependencies there.

The correct patch is here:

http://people.apache.org/~rjung/patches/jmeter-user_classpath-load_jars-v2.patch

It adds the jar search to addURL() (called by TestPlan) instead of
addPath() (called by the main JMeter class).

addURL() only adds items to the loader, addPath() also to the system
classpath.

In the meantime I tested the patch and it works correct for me.

Now there's another thing that would be nice: being able to use a jmeter
property in the user defined class path in TestPlan.

Unfortunately that property is used very early and the resolution of
properties returns with an "Not running version, return raw function
string" error from FunctionProperty.

Is there a way to force a property replacement? Or how can we support
using a property in the user defined class path inside a test plan.

The use case is somewhat clear: you want to be able to collect your
dependency jars in some directory. When you relocate the directory you
don't want to edit all our test plans referring that directory. Instead
use a property in the test plans and set it during jmeter startup to
point to your current jar file directory.

Any hints would be helpful.

What about the patch for automatic jar file exclusion? Any objections?
Should I file a bugzilla before committing (it seems we now do it for
nearly every change)?

Regards,

Rainer

Mime
View raw message