Hello Rainer, So your patch only concerns Test Plan which do "Add directory or jar to classpath" ?
If so, some notes about patch: - Shouldn't code be within try/catch ? as if a MalformedURLException is thrown there are big chances that the rest won't work Regarding Bugzilla, I think it is better to open one for this enhancement. Regards Philippe On Mon, Aug 12, 2013 at 2:13 PM, Rainer Jung <[email protected]>wrote: > 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 <[email protected]> > 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 > -- Cordialement. Philippe Mouawad.
