Bug 56662 - Save as xml in a listener is not remembered
Summary: Save as xml in a listener is not remembered
Status: RESOLVED FIXED
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.10
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-24 07:08 UTC by Kasper Janssens
Modified: 2014-07-05 13:05 UTC (History)
1 user (show)



Attachments
Test jmx plan as requested (5.23 KB, text/plain)
2014-06-24 11:21 UTC, Kasper Janssens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kasper Janssens 2014-06-24 07:08:09 UTC
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.
Comment 1 Sebb 2014-06-24 10:58:51 UTC
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.
Comment 2 Kasper Janssens 2014-06-24 11:21:06 UTC
Created attachment 31746 [details]
Test jmx plan as requested
Comment 3 Sebb 2014-06-25 01:07:40 UTC
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.
Comment 4 Kasper Janssens 2014-06-25 07:52:04 UTC
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?
Comment 5 Sebb 2014-06-25 13:50:10 UTC
(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.
Comment 6 Kasper Janssens 2014-06-25 13:56:16 UTC
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.
Comment 7 Sebb 2014-06-25 14:54:02 UTC
(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.
Comment 8 Kasper Janssens 2014-06-25 15:10:28 UTC
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.
Comment 9 Philippe Mouawad 2014-07-05 13:05:38 UTC
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