jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: user.classpath, search_path and many jar files
Date Mon, 12 Aug 2013 12:59:31 GMT
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 <rainer.jung@kippdata.de>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 <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
>



-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message