Summary: | Save as xml in a listener is not remembered | ||
---|---|---|---|
Product: | JMeter - Now in Github | Reporter: | Kasper Janssens <kasper.janssens.android> |
Component: | Main | Assignee: | JMeter issues mailing list <issues> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | p.mouawad |
Priority: | P2 | ||
Version: | 2.10 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | Test jmx plan as requested |
Description
Kasper Janssens
2014-06-24 07:08:09 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. 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 |