jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Epp, Jeremiah W (Contractor)" <>
Subject RE: JMeter JMX file format
Date Fri, 12 Aug 2016 23:15:00 GMT
> -----Original Message-----
> From: sebb []
> Sent: Friday, August 12, 2016 4:01 PM
> To:
> Subject: Re: JMeter JMX file format
> On 12 August 2016 at 20:33, Epp, Jeremiah W (Contractor) <>
> wrote:
>> 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.

Other way around.  JMX created in 2.13 opened in 2.8 but blew up at runtime
somehow.  I don't remember the details beyond being peeved at Ubuntu RelEng
for packaging a prehistoric JMeter.

I'm not sure what the bug report for that would even be?

>> 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.

Doesn't it strike you as at least a little bit of a bad idea to use an
undocumented serialisation of a complex recursive data structure as the
"human readable" format, though?

We've definitely found it a huge pain in the butt to work with. :/

>>  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.

I went into a little more detail on this topic in the DSL discussion thread.
In brief: the structure of a JMX document _partially_ lacks correspondence
to the structure of the test plan it represents, confounding correct and
safe manipulation.  That's a bad thing.

> [Human languages are a 'horrible mess' if considered from the perspective
> of automatically parsing them.]

Haha, this is very true, if a non sequitur.

>> Interesting. Doc link?
Thanks.  Not what I expected, but enlightening in its own way.

>> 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?

JMX import and export is legacy code.  It works.  It's content.  Leave it
alone.  DSL import and export can exist concurrently-- philosophically, it's
no different from how JTL supports CSV and XML.

Users can save to either format unless a test plan uses new features (such
as those mentioned in the DSL thread) that exceed the semantic capabilities
of the JMX format.  In that case, error if users attempt to export JMX with
a notification that they have to use the new format (and why).

All right, I'm out.  Have a good weekend!


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.

View raw message