jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: CompoundVariable classfinder.functions
Date Wed, 11 Jan 2012 16:55:41 GMT
On 11 January 2012 16:07, Mark Collin <mark@ardescosolutions.com> wrote:
> Sorry, I'm not being clear.
>
> With the maven plugin I've been tweaking they aren't in a lib/ext directory
> because it doesn't exist.  I was sending everything over the classpath, but
> that is obviously not going to work so instead I'm making the plugin create
> a lib/ext dir and copying the JMeter component artefacts that the plugin
> references into it.

Or use the search_dir property.

> This is probably more of a mavenised JMeter issue than anything else because
> you don't know where the jars are physically held and you need to rely on
> maven telling you.
>
> With a standard implementation of JMeter this is unlikely to be a problem as
> everything is already in the correct place.
>
> The advantage to adding this to the normal JMeter implementation would be
> that you wouldn't have to put components in the lib/ext directory for them
> to be automatically picked up, it would be able to use anything on the
> classpath.

The disadvantage is that JMeter will then load all the classes in all
the jars on the classpath, so that is not something that should be
enabled by default.

> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: 11 January 2012 15:19
> To: dev@jmeter.apache.org
> Subject: Re: CompoundVariable classfinder.functions
>
> On 11 January 2012 15:14, Mark Collin <mark@ardescosolutions.com> wrote:
>> In that case it would seem like the path of least resistance is to
>> copy all JMeter component jars into the lib/ext folder.
>
> They already are there.
>
>> The other option would be to enforce a naming structure for JMeter
>> components (e.g. they must always start with "ApacheJMeter_") then you
>> could scan the classpath and only pick up JMeter components to search
>> through for functions.
>
> No point that I can see.
>
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: 11 January 2012 13:35
>> To: dev@jmeter.apache.org
>> Subject: Re: CompoundVariable classfinder.functions
>>
>> On 11 January 2012 13:18, Mark Collin <mark@ardescosolutions.com> wrote:
>>> Looking through the code whilst debugging a problem with my maven
>>> implementation today I found out that CompoundVariable in core ->
>>> engine -> util searches for functions in jars that are in the
>>> search_path and the lib/ext folder but it completely ignores anything
>>> in
>> the classpath.
>>>
>>>
>>>
>>> However when JMeter loads it checks the java.class.path to report
>>> which jars are available to it which can be slightly confusing when
>>> you get a
>>>
>>>
>>>
>>> Jmeter.engine.util.CompoundVariable: Did not find any functions
>>>
>>>
>>>
>>> I'm thinking of adding a patch to check the classpath rather than the
>>> lib/ext dir as looking at the logs everything in the lib/ext dir
>>> seems to be added to the classpath anyway (I haven't worked through
>>> the code to see if this assumption is correct yet, but everything in
>>> lib/ext is logged as being in the classpath when in DEBUG mode so I
>>> assume that's
>> correct).
>>>
>>>
>>>
>>> Is there a reason you aren't checking the classpath?
>>>
>>>
>>>
>>> Would I be wasting my time changing this?
>>
>> Possibly.
>>
>> The way that JMeter searches for classes is quite complicated, as you
>> have found.
>> It's important that it restricts the search when looking for JMeter
>> add-ons, otherwise it can end up loading lots of unwanted classes.
>>
>>>
>>> --
>>> This message contains confidential information and is intended only
>>> for
>> the individual named. If you are not the named addressee you should
>> not disseminate, distribute or copy this e-mail. Please notify the
>> sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>>>
>>> If you have received this email in error please notify
>>> postmaster@ardescosolutions.com
>>
>> --
>> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and delete
> this e-mail from your system. If you are not the intended recipient you are
> notified that disclosing, copying, distributing or taking any action in
> reliance on the contents of this information is strictly prohibited.
>>
>> If you have received this email in error please notify
>> postmaster@ardescosolutions.com
>
> --
> This message contains confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you
are notified that disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited.
>
> If you have received this email in error please notify postmaster@ardescosolutions.com

Mime
View raw message