jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JMeter JMX file format
Date Fri, 12 Aug 2016 20:00:50 GMT
On 12 August 2016 at 20:33, Epp, Jeremiah W (Contractor) <jepp@cas.org> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Friday, August 12, 2016 1:02 PM
>> To: dev@jmeter.apache.org
>> Subject: Re: JMeter JMX file format
>>
>>On 12 August 2016 at 15:38, Epp, Jeremiah W (Contractor) <jepp@cas.org>
>>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.
>

Mime
View raw message