jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
Subject BUG 61567
Date Sat, 11 Nov 2017 21:41:48 GMT
Hello,
Analyzing bug 61567 , I end up thinking that what we're doing in the below
method is not correct:

   - ClassFinder#getClasspathMatches

This method does the following:

   - It takes a list of jars in search_path
   - It takes the classpath
   - For each entry in classpath , it tests if it ends with one of the jar
   of the first list
   - If one match is found, the entry will be returned , otherwise it will
   be ignored

So what is triggering the bug is the following, as search_path is empty,
only content of lib/ext is used.

So first list consist of :

   - ApacheJMeter_jms.jar
   ApacheJMeter_junit.jar
   ApacheJMeter_native.jar
   ApacheJMeter_ftp.jar
   ApacheJMeter_components.jar
   /data/jmeter/jmeters/apache-jmeter-3.3/lib/ext
   ApacheJMeter_ldap.jar
   ApacheJMeter_mail.jar
   ApacheJMeter_tcp.jar
   ApacheJMeter_http.jar
   ApacheJMeter_java.jar
   ApacheJMeter_core.jar
   ApacheJMeter_functions.jar
   ApacheJMeter_jdbc.jar
   ApacheJMeter_mongodb.jar

Classpath consists of many entries and specifically , JMeter artifacts end
with -3.3.jar

None of the entries are added due to endsWith test failing, example:

Testing if /MAVEN
.m2/repository/org/apache/jmeter/ApacheJMeter_functions/3.3/ApacheJMeter_functions-3.3.jar
ends
with ApacheJMeter_jms.jar *will return false*

As a consequence, no function is found


*One fix would be in JMeter to suffix artifacts in bin and lib/ext with the
version number.*

*But is this behaviour correct ?*

-- 
Regards.
Philippe M.

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