Summary: | Order of elements in .jmx files changes with no reason | ||
---|---|---|---|
Product: | JMeter - Now in Github | Reporter: | Jens Vo <jens> |
Component: | Main | Assignee: | JMeter issues mailing list <issues> |
Status: | RESOLVED FIXED | ||
Severity: | major | ||
Priority: | P2 | ||
Version: | 2.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Attachments: |
Screenshot of diff tool
Patch to core\org\apache\jmeter\testelement\AbstractTestElement.java Patch to the previously supplied patch |
Description
Jens Vo
2007-05-03 05:23:17 UTC
Created attachment 20116 [details]
Screenshot of diff tool
In total, there are 168 such pseudo-differences in one .jmx file (7193 lines)
I tried hacking around the source code a bit, replacing HashMaps by LinkedHashMaps in places that looked promising, but it didn't seem to fix the problem, and unfortunately I currently don't have time for thorough debugging and fixing As you found, the problem is that the test plan is saved in a hash tree, and it is non-trivial to fix (if it is possible). This is not a JMeter bug, so changing to enhancement. The re-ordering might disappear once the equals() and hashcode() methods are regularised. But when I attempted that some while back, various problems appeared. As a work-round, you could write an XSLT sheet to order the JMX before saving it. Created attachment 20287 [details]
Patch to core\org\apache\jmeter\testelement\AbstractTestElement.java
Okay, the supplied patch should do the job.
Note that if you open a file (e.g. "foo.jmx") that has previously been saved
with an unpatched version and save it with the patched version (as "bar.jmx"),
there will (most likely) still be plenty of XML elements interchanged. However,
if you then open "bar.jmx" again and save it as "baz.jmx", the files "bar.jmx"
and "baz.jmx" should be identical.
Thanks very much - I've applied the patch to SVN in r542902. I'll create a nightly build later - perhaps you could check it out and report back? Hmm, I installed nightly build r542903 and tried to open saved test plans (both saved with old versions and with the current nightly), and I reproducably get a ConcurrentModificationException: 2007/05/31 12:34:41 ERROR - jmeter.JMeter: Failure loading test file java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry (LinkedHashMap.java:365) at java.util.LinkedHashMap$ValueIterator.next(LinkedHashMap.java:380) at org.apache.jmeter.testelement.property.PropertyIteratorImpl.next (PropertyIteratorImpl.java:50) at org.apache.jmeter.testelement.AbstractTestElement.mergeIn (AbstractTestElement.java:276) at org.apache.jmeter.testelement.AbstractTestElement.addTestElement (AbstractTestElement.java:115) at org.apache.jmeter.testelement.TestPlan.addTestElement (TestPlan.java:222) at org.apache.jmeter.gui.tree.JMeterTreeModel.addSubTree (JMeterTreeModel.java:83) at org.apache.jmeter.gui.GuiPackage.addSubTree(GuiPackage.java:457) at org.apache.jmeter.gui.action.Load.insertLoadedTree(Load.java:141) at org.apache.jmeter.gui.action.Load.insertLoadedTree(Load.java:168) at org.apache.jmeter.JMeter.startGui(JMeter.java:226) at org.apache.jmeter.JMeter.start(JMeter.java:314) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.jmeter.NewDriver.main(NewDriver.java:183) Why this does not happen at my "privately patched" version here I don't really know, but it may have to do with the fact that the rest of my sources are more or less in 2.2 state. I'll install the source files from the current nightly and give it another try. For now, you may probably want to rollback the AbstractTestElement because the above error is a definite showstopper for the nightly (unless you want to take the effort and find a fix to the ConcurrentModificationException without rolling back the changes introduced with the patch). Created attachment 20296 [details] Patch to the previously supplied patch Okay, I guess my previous patch simply went a bit too far. In order to correct it, apply the new patch to revision 542902 of the AbstractTestElement class. OK, applied in r543291. Unfortunately the test suite did not detect this error. It seems to affect only GUI tests, and the test cases don't (can't) use the GUI. This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1933 |