On 11 January 2012 16:07, Mark Collin <m...@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:seb...@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 <m...@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:seb...@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 <m...@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
>>> postmas...@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
>> postmas...@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 
> postmas...@ardescosolutions.com

Reply via email to