CompoundVariable classfinder.functions
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? -- 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
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
RE: CompoundVariable classfinder.functions
In that case it would seem like the path of least resistance is to copy all JMeter component jars into the lib/ext folder. 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. -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
