DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22225>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22225

non GUI mode: unable to load a custom property file

           Summary: non GUI mode: unable to load a custom property file
           Product: JMeter
           Version: 1.8.1
          Platform: All
               URL: any
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Major
          Priority: Other
         Component: Main
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
                CC: [EMAIL PROTECTED]


nonGUI mode:
1)unable to load a custom property file, different from jmeter.properties
2)unable to load jmeter.properties file from a different directory other then 
default $JMETER_HOME/bin

It seems that org.apache.jmeter.save.SaveService.readAndSetSaveProperties()
passes to org.apache.jmeter.util.JMeterUtils.getProperties(...) the 
String "jmeter.properties" instead of a runtime parameter eventually taken from 
the "-p" argument on command line.
This seems to lead to the first two consequences above outlined.

3)default property file (=bundle file org/apache/jmeter/jmeter.properties) not 
present in any package of distribution

in this case, whenever org.apache.jmeter.util.JMeterUtils.getProperties(...) 
could not find jmeter.properties on current -run- directory, it searches for 
the above bundle file, which should be in classpath - i.e. in any of the dist 
jars either in $JMETER_HOME/lib and $JMETER_HOME/lib/ext (which seems to be not 
at the moment)

4)the failure in finding bundle file org/apache/jmeter/jmeter.properties 
doesn't throw a java.io.IOException (see 
org.apache.jmeter.util.JMeterUtils.getProperties(...) catch block) but an 
unchecked exception, caught by 
org.apache.jmeter.save.SaveService.readAndSetSaveProperties()

in this case it would - maybe - better the improve the message semantic of the 
catch block

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to