On 12 August 2016 at 20:33, Epp, Jeremiah W (Contractor) <[email protected]> wrote: >> -----Original Message----- >> From: sebb [mailto:[email protected]] >> Sent: Friday, August 12, 2016 1:02 PM >> To: [email protected] >> Subject: Re: JMeter JMX file format >> >>On 12 August 2016 at 15:38, Epp, Jeremiah W (Contractor) <[email protected]> >>wrote: >>> >>> Part of the problem there is JMX isn't versioned. >> >> There *is* some versioning info; it's perhaps not changed as frequently as >> it should be. But any changes are upwards compatible. > > Okay, egg on my face. Somehow I never actually noticed the version="1.2" > and properties="1.8" attributes on the <jmeterTestPlan>. > > Though it's true that it NEEDS to be changed when the format changes or it's > somewhat meaningless. (For example it probably should have changed some time > between 2.8 and 2.13 because I'm pretty sure we found a break in there.)
Is there a bug report? AFAIK a JMX created in 2.8 will still run in 2.13 unless it uses a test element that has been retired. >> However JMeter uses XStream to serialise the classes that form the nodes, >> so the format is defined by that. > > Oh god, it really does work exactly like I thought it did. It is quite > literally implementation defined. Of course: that's what serialisation is designed to do. It is however much more portable and readable than Java serialisation. > No wonder it's such a horrible mess. It works perfectly well for the purpose for which it was designed. Calling it a horrible mess does not help. [Human languages are a 'horrible mess' if considered from the perspective of automatically parsing them.] >> config files to define shorthand aliases to reduce the file size. > > Interesting. Doc link? https://svn.apache.org/repos/asf/jmeter/trunk/bin/saveservice.properties >> Otherwise of course the source code is available. > > Source code is not documentation. > > Especially _that_ code. I actually _tried_ to figure out what the hell was > happening in SaveService at a few points and it's not easy reading. You need to understand XStream as well. >>> In my mind, this is the major motivation for a test plan DSL: retain >>> support for the "legacy" JMX as much as possible (read and write), but >>> otherwise have a clean break that lets the project move forward sanely. >> >> I'm not sure how you can do that unless the DSL generates JMX. > > What? I think implementing a DSL sort of implies there will be an > interpreter for it... Well yes, but if JMeter also continues to support reading and writing the current JMX format how can one have a clean break? > Cheers, > Wyatt > > Confidentiality Notice: This electronic message transmission, including any > attachment(s), may contain confidential, proprietary, or privileged > information from Chemical Abstracts Service ("CAS"), a division of the > American Chemical Society ("ACS"). If you have received this transmission in > error, be advised that any disclosure, copying, distribution, or use of the > contents of this information is strictly prohibited. Please destroy all > copies of the message and contact the sender immediately by either replying > to this message or calling 614-447-3600. >
