I try to save the output file of a listener (doesn't seem to matter which kind of listener, but I try the 'View Results Tree' listener) as xml. I can check the 'Save as Xml' flag, and when I then run the jmeter plan, without closing the gui, I get an xml output. As soon as I close the gui and I try again the output changes to csv, but in the jmx file itself there is still an xml element true for that ResultCollector. I have the same issue when I run headless. I tried changing the jmeter.properties to jmeter.save.saveservice.output_format=xml and that seems to do the trick, but that would likely mean that I cannot output csv format anymore. http://stackoverflow.com/questions/24365570/jmeter-save-listener-configuration-as-xml-not-working Somebody answered here that he thought there was a regression in the versions 2.10 and 2.11 that triggered this.
Works fine for me using JMeter 2.10 and 2.11 on MacOs. Make sure you save the JMX file before exitting. If you are still having problems, create a JMX file containing just the Listener and attach to this issue.
Created attachment 31746 [details] Test jmx plan as requested
I agree that something has gone wrong with 2.11 - and 2.10 They both fail to preserve most of the settings. This does seem to have been fixed in the current code; if you are willing to try a nightly build it would be interesting to know if it fixes the issue for you. When I tested earlier, I created the test plan with the current test code and tried it in 2.11. This worked. However, when I retested by creating the plan in 2.11 it failed. The difference is very subtle. In 2.9 (and current code) the config section starts as follows: <objProp> <name>saveConfig</name> <value class="SampleSaveConfiguration"> However in 2.10 and 2.11 the <name> line is missing; this causes the problem. Unfortunately it looks like test plans created in 2.10 and 2.11 will not be upwards compatible. Maybe there is a way to detect the missing tag. If it cannot be automatically added, then JMeter could provide a warning.
Confirmed that the dev version solves the problem, however, I don't feel so comfortable with everybody switching over to a development version. Is there any chance of having this patch retrofitted on the 2.11 version, in a short timeframe? Or is there something else we can do?
(In reply to Kasper Janssens from comment #4) > Confirmed that the dev version solves the problem, however, I don't feel so > comfortable with everybody switching over to a development version. Fair enough. Thatnks for confirming it fixes the issue. > Is there > any chance of having this patch retrofitted on the 2.11 version, in a short > timeframe? We don't do retrofits; the fix will be in the next release (2.12) which will be produced from the current trunk - i.e. the dev version - when we have time. > Or is there something else we can do? If the JMX files are created and maintained in 2.9 (or current dev) they should work OK in 2.11. Or you can fix up the JMX file manually to add the missing line. However 2.10 and 2.11 will lose the line if the plan is re-saved after editting.
So, do I interpret your statement correctly when I say that the current code in the trunk IS the 2.12 version (in the future)? Because in that case we might consider using the dev version of course, I'm just a bit reluctant to use it if there would still be considerable code flux. Do I also understand correctly that you don't really have a strict release date planned for 2.12 (important factor when we considering using the dev version, if it's still quite some time away we might have to go for the dev version as it's a bit of an annoying bug.)? I recall we had problems using the 2.9 version (don't recall which ones anymore) so that's not really an option right now. Thanks for the clarification.
(In reply to Kasper Janssens from comment #6) > So, do I interpret your statement correctly when I say that the current code > in the trunk IS the 2.12 version (in the future)? Not exactly. There may be additional changes before 2.12 is released. > Because in that case we > might consider using the dev version of course, I'm just a bit reluctant to > use it if there would still be considerable code flux. > > Do I also understand correctly that you don't really have a strict release This is an all-volunteer effort; releases are done when there are resources available. > date planned for 2.12 (important factor when we considering using the dev > version, if it's still quite some time away we might have to go for the dev > version as it's a bit of an annoying bug.)? Note that the nightly builds are not formal releases, and are not guaranteed. > I recall we had problems using the 2.9 version (don't recall which ones > anymore) so that's not really an option right now. I was only suggesting using 2.9 to maintain the test plans, not run them. > Thanks for the clarification. Having said tah, I have just been ahving a look at what changes could have caused the problem. It looks like it might not be a JMeter code problem, but it might be the version of XStream. It so happens that 2.10 and 2.11 switched to using XStream 1.4.4 (from 1.4.2); the current dev code uses 1.4.6. This appears to be the culprit. So try replacing lib/xstream-1.4.4.jar with version 1.4.6 It seemed to help when I just tested it. You can get the jar from http://xstream.codehaus.org/ or Maven http://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream/ It looks like there is 1.4.7 also available; not yet tried.
I wasn't trying to rush you guys for releasing, I realize it's a volunteer effort, that's all good, just trying to find out which way to go. But thanks for the effort, because indeed, swapping in the 1.4.6 library does the trick. So I guess we'll be doing that and are going to stick with the 2.11 branch right now. Thanks for the help, issue can be closed now as far as I'm concerned.
Affects 2.10 and 2.11. Date: Sat Jul 5 13:04:19 2014 New Revision: 1608012 URL: http://svn.apache.org/r1608012 Log: Bug 56662 - Save as xml in a listener is not remembered Fixed by upgrade of xstream to 1.4.6 Bugzilla Id: 56662 Modified: jmeter/trunk/xdocs/changes.xml
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3388